fix(ios): map usbmux connect result codes to the right verdict - #1523
Merged
Conversation
usbmuxd answers Connect with a result code, and every non-zero code collapsed into one 'Failed to connect' error carrying a cable hint. Probing the daemon on this host for the two codes that matter: an unknown DeviceID answers 2, and a closed port on an attached device answers 3. Result 2 means the device went away between ListDevices and Connect. It now raises the same unattached verdict as a missing ListDevices entry, so a CoreDevice device falls back to its network tunnel instead of failing with a cable hint while Wi-Fi is available — the gap #1517 left open. Result 3 means the device is reachable and only the runner port is not bound yet, which is the normal state while the runner starts. Telling the user to check the cable was wrong; it now says so. Adds hermetic multi-device coverage for #1521: selection follows the UDID rather than list position, and a UDID sharing a prefix with another device never matches.
Size Report
Startup median (7 runs, lower is better):
Top changed chunks:
|
thymikee
added
the
ready-for-human
Member
Author
|
Clean review at Residual risk: #1521’s real multi-device and unpaired/untrusted hardware matrix remains open; no separately authorized cross-vendor review was performed. |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tackles the verifiable half of #1521, and closes a gap #1517 left open.
The gap
usbmuxd answers
Connectwith a result code, and every non-zero code collapsed into a single error with a cable hint:I probed the daemon on this host rather than trusting documentation, using the real cabled iPhone:
Result 2 (device gone) never reached the fallback. #1517 keys its tunnel fallback off
usbmuxDeviceAttached: false, which only theListDevicespath set. If a device disappears betweenListDevicesandConnect, a CoreDevice device failed with a cable hint while its Wi-Fi tunnel was sitting there working. It now raises the same unattached verdict, so the fallback runs.Result 3 (port not bound) got the wrong advice. The cable is fine and the device is unlocked — the runner just is not listening yet, which is the normal state while it starts. It now says that instead of blaming the cable.
#1521 coverage
The live two-device matrix still needs a second iPhone, but the substance of "is UDID→device selection unambiguous" is now locked down hermetically against the fake usbmuxd:
ConnectConnectis attemptedBoth result-code tests were verified revert-sensitive — restoring the collapsed handler fails them.
Remaining in #1521
Two concurrent sessions on two cabled devices, and the unpaired/untrusted legs. Those still need hardware; I have updated #1521 rather than closing it.
pnpm check:affected --runpasses.