Repository navigation
fix(apple): start no host runner cache build while a provider serves Apple tooling - #3225
Conversation
…Apple tooling The readiness keep-hot prewarm called prewarmAppleRunnerCache with no request id, so it reached the host xcodebuild even when a scoped Apple tool provider served the request. On macOS every provider-scenario iOS open started a real build-for-testing in the background; the lease-expiry parity test then hit the hermetic signal guard when teardown pkill'd that build's children. The cache prewarm is speculative host work, so it now declines (debug diagnostic ios_runner_cache_prewarm_unavailable) while a provider serves Apple tooling, the same rule the macOS helper build already follows.
Size Report
Startup median (7 runs, lower is better):
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
|
I found no problems in 9eec6cc. The runner prewarm gate and host port now skip the host build while a provider serves Apple tooling, and nothing else in the diff changes behavior. All 19 checks pass, and the platform-apple unit tests and provider scenarios cover the touched code. I know of no conflicts, and nothing else stands in the way of merging. I did not run the test suites, the macOS target test or the provider-scenario instrumentation myself. Those numbers come from the PR body. The new test calls prewarmAppleRunnerCache directly inside withAppleToolProvider, so it does not drive the keepHot route through ensureAppleReady. I checked that AsyncLocalStorage context survives Two notes that need no change here. Embedders that supply an appleToolProvider resolver but build the runner with host xcodebuild lose the speculative runner build, which costs some first-command latency. So "production unchanged" holds only for the default daemon. Also, doctor.ts:44 still starts a real prewarm outside any provider scope, which the PR body already lists as a follow-up. |
thymikee
added
the
ready-for-human
|
1 participant
Summary
On macOS,
remote-proxy-parity.test.ts> "proxy lease expiry tears the session down…" fails (also on main): the hermetic signal guard refusespkill -TERM/-KILL -P <pid>aimed at a realxcodebuild build-for-testingthe test started by accident. Linux passes because it has noxcodebuild.The build comes from readiness keep-hot (
ensureAppleReady→appleAutomation.keepHot→prewarmAppleRunnerCache(device, {})). It never asked either provider seam. It also passes no request id, so ADR 0001's request-id-scoped runner provider could never cover it for proxied requests. Across provider scenarios, 52 keep-hot calls started real host prewarm work.prewarmAppleRunnerCacheis speculative host work. It now declines, with a debugios_runner_cache_prewarm_unavailablediagnostic, while a scoped Apple tool provider serves the request. That is the rule the macOS helper build already follows. Production behavior is unchanged: the daemon never scopes an Apple tool provider. The hermetic guard is untouched.4 files; the scope query goes through the runner host port (R77).
Not covered:
doctor.test.tsstill starts 5 real warmups through host-scopedappleRunnerWarmupCheck. Its world supplies no Apple providers, so it is a separate follow-up.Validation
Tested commit
9eec6cc7a8, macOS:runner-client-prewarm.test.ts: fails without the gate, passes with it.vitest run --project provider-integration test/integration/provider-scenarios/: 70/70 files. Instrumented real cache prewarms: 57 → 5 (doctor only).pnpm check:affected --run: all runnable checks pass.Linux has not been run locally; the PR's Integration Tests job covers it.