the documented pattern for avoiding concurrent connects is to check is_connecting() before calling connect(), but there's no synchronization — another task can start connecting in the window between the check and the call.
is_connecting walks all devices and checks for transitional states (core/device.rs:137-166), but it's a point-in-time snapshot. there's no mutex, semaphore, or atomic guard around connect().
this is already documented as "concurrent connection operations are not supported" (network_manager.rs:520-527), but the suggested is_connecting check doesn't actually prevent the race. worth considering whether a Mutex or try_connect pattern would be more robust.
the documented pattern for avoiding concurrent connects is to check
is_connecting()before callingconnect(), but there's no synchronization — another task can start connecting in the window between the check and the call.is_connectingwalks all devices and checks for transitional states (core/device.rs:137-166), but it's a point-in-time snapshot. there's no mutex, semaphore, or atomic guard aroundconnect().this is already documented as "concurrent connection operations are not supported" (
network_manager.rs:520-527), but the suggestedis_connectingcheck doesn't actually prevent the race. worth considering whether aMutexortry_connectpattern would be more robust.