refactor(ios): drop the transport seam usbmux-first made dead - #1540
Conversation
The physical-device control exposed resolveRunnerTransport returning either a network tunnel or usbmux, from before the route resolver decided transports. Since #1517 the resolver returns a usbmux route for XCTest devices and for any attached CoreDevice one, and only reaches the control after usbmux has reported the device unattached — so the control is asked exclusively for a tunnel. That left the usbmux arm with no live producer or consumer: the branch handling it in the resolver was unreachable, and the XCTest implementation returning it was called only by a test. Collapse the union to the one shape that is resolved, rename the seam to say what it does, delete the unreachable branch, and let XCTest reject a tunnel lookup the way it already rejects app inventory and process lookup — it has no CoreDevice tunnel, which is why the resolver never asks it for one.
Size Report
Startup median (7 runs, lower is better):
Top changed chunks:
|
|
Re-reviewed at |
|
Taking the documented-blocker option, because I cannot produce an exact-head physical capture right now and I would rather say that than pass off an earlier one as fresh. The concrete blockerBoth physical devices are unreachable as of this comment:
Why I believe this is safe without a fresh captureThis PR contains no behavioural change. The entire production delta is: - const transport = await control.resolveRunnerTransport(device, timeoutBudgetMs);
- if (transport.kind === 'usbmux') {
- return buildUsbmuxRoute(device, port);
- }
- const tunnelIp = transport.tunnelIp;
+ const { tunnelIp } = await control.resolveTunnel(device, timeoutBudgetMs);plus the type collapse and the XCTest rejection. The deleted branch was unreachable by construction: the only control that reaches that line is CoreDevice, whose implementation returns Equivalent live evidence already exists on functionally identical routing:
Nothing between those captures and this head changes which route is selected; this PR only removes a path that could never be selected. At this head I can offer the deterministic evidence: If you would rather hold this until a device is back, that is a reasonable call and I am happy to run the capture then — it needs the phone cabled and unlocked for the usbmux leg, then unplugged for the fallback leg. |
|
Re-reviewed unchanged head Residual risk is the unavailable/locked physical hardware preventing a fresh capture. One evidence correction for traceability: the cited #1517 Wi-Fi fallback capture recorded 4 |
thymikee
added
the
ready-for-human
|
1 participant
Answering "is there code we can safely drop now that usbmux is primary?" — yes, this much.
What went dead
IosPhysicalDeviceControlexposed:That predates #1517, when the control still chose the transport. Since #1517 the route resolver chooses: it returns a usbmux route for an XCTest device, and for a CoreDevice device too, reaching the control only after usbmux has reported the device unattached. At that point the sole question left is "what is the tunnel address".
So the
usbmuxarm has no live producer or consumer:if (transport.kind === 'usbmux')branch was unreachable — the only control that gets that far is CoreDevice, which always answersnetwork{ kind: 'usbmux' }was called only from a test; production returns a usbmux route before itChange
IosPhysicalDeviceTunnel = { tunnelIp: string | null }— one shape, so no discriminator to carryresolveRunnerTransport→resolveTunnel, which is what it now does; the old name advertised a decision this seam no longer makesBehaviour is unchanged: every path that ran before runs the same way. This removes a false affordance rather than a feature — the interface implied XCTest devices resolve a transport, when the transport question was settled upstream.
Testing
The one test that exercised the dead path now asserts the rejection instead of a value production never produced, matching its sibling tests for the other unsupported XCTest operations.
physical-device-controlandrunner-transportsuites pass (19 tests); typecheck and lint clean.On the gate run
check:affectedreports failures inhelp-conformance-bench,install-source(unzip exited with code 9),owner-identity,device-claimsandandroid-recording. Two of those are assertion failures, which I would normally treat as blocking rather than flake — so I checked rather than assumed: all 51 of those tests pass in isolation, both with and without this change, and none of them are reachable from a diff that touches only Apple physical-device control, the Apple route resolver, and one Apple test. The host has been driving real devices and xcodebuild for hours;unzipfailing with a subprocess code and a process-liveness check flipping are both load-sensitive.Worth a separate look if they recur on a quiet machine — I would rather flag that than bury it.