You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 5c4a3eb
Browse filesBrowse the repository at this point in the historyBrowse files
fix(apple-runner): the preflight marker alone decides the restart
The rule asked for two facts: the marker the readiness preflight puts on its way out, and a
recorded budget in the same details. A device run says those two rarely arrive together. Wedging a
warm runner (`kill -STOP`, then a `tap`) produced "Runner did not accept connection" and invalidated
with `runner_connect_failed_before_command_send`; the budget-carrying shape appeared only post-send,
where replaying is not safe and no restart is wanted. A preflight reaches the caller in whatever
shape its connect loop ended with — a refusal, an exhausted probe, a killed `simctl` fallback, a post
that ran out of its budget — and only the last of those carries `timeoutMs` at the top level.
The marker is the fact the decision needs, so it is now the only one asked for. `hasCommandDeadline`
and `hasReadinessPreflightDeadline` go with it, `shouldRestartAfterReadinessPreflightError` reduces
to the table lookup and is gone, and `isRunnerReadinessPreflightFailure` loses its only consumer.
`connectRetry` left the verdicts too: the marker is applied after the connect loop has returned, so
no loop can ever consult it.
The mocked decision tests stop asserting a message, which is what makes them enough: the shape is no
longer part of the rule, and the shapes a real preflight produces are what the device run recorded
rather than what a fixture invents. Restoring the budget conjunction turns the refusal and the
`fetch failed` cases red again, so the tests still discriminate the claim.
0 commit comments