Summary
The device polling loop in abstractDeviceTracker.ts can stop permanently after a single transient failure.
Problem
In queryDevicesLoop:
the next poll is only scheduled on the success path
the catch block only logs the error and does not schedule a retry
Android and iOS trackers only start this loop once during startup, so a temporary adb/xcrun failure can silently disable device discovery until the extension is restarted.
Impact
Device discovery may stop unexpectedly
Users can lose Network Inspector device visibility without clear recovery
Manual extension restart is required to recover
Expected Behavior
Polling should continue regardless of whether the previous iteration succeeds or fails, while still avoiding overlapping queries.
Proposed Fix
Always schedule the next iteration in finally (guarded by stop state), so transient failures are self-healing.
Summary
The device polling loop in abstractDeviceTracker.ts can stop permanently after a single transient failure.
Problem
In queryDevicesLoop:
the next poll is only scheduled on the success path
the catch block only logs the error and does not schedule a retry
Android and iOS trackers only start this loop once during startup, so a temporary adb/xcrun failure can silently disable device discovery until the extension is restarted.
Impact
Device discovery may stop unexpectedly
Users can lose Network Inspector device visibility without clear recovery
Manual extension restart is required to recover
Expected Behavior
Polling should continue regardless of whether the previous iteration succeeds or fails, while still avoiding overlapping queries.
Proposed Fix
Always schedule the next iteration in finally (guarded by stop state), so transient failures are self-healing.