Repository navigation
Flaky on macos-latest: 3044 owner-lifetime host does not answer get_protocol_info within 10s #3289
Description
Summary
On macos-latest, the CI job "RPC supervisor exit" can fail in test/suite/regressions/3044-rpc-owner-lifetime.test.ts because the spawned host does not answer get_protocol_info within 10 s. Cleanup then refuses the PID whose command changed.
Evidence
- Run https://github.com/code-yeongyu/senpi/actions/runs/38448054029 (PR ci(catalog): regenerate the refresh branch on main data changes and refuse hand commits on it #3275, head 393e302). Attempt 1 had 1 failed / 26 passed; attempt 2 had 3 failed / 24 passed. Each failure reads:
{"type":"failure","error":"Error: spawned RPC socket host did not answer get_protocol_info within 10000ms\nsenpi rpc host supervisor: signal:SIGTERM shutdown"}, followed byError: refusing changed process <pid>fromtest/helpers/rpc-owner-processes.ts:126during cleanup. - ci(catalog): regenerate the refresh branch on main data changes and refuse hand commits on it #3275 changes only CI workflows,
scripts/check-bot-branch-commits.*and changelogs, none of which this job executes. ci(releasability): report catalog drift as a warning; the release regenerates and commits it #3274, merged with the same 53 main commits, passed the same job. - The same head passes locally 3/3 (
npm ci,npm run build, then the job's exact vitest command; 5 files / 27 tests each run, on an Apple-silicon Mac).
Expected
The owner-lifetime regression is deterministic on macos-latest: a slow runner extends the wait instead of failing on a fixed 10 s protocol-info deadline. And when the host does not start, cleanup reports the real cause instead of refusing changed process.
Hypothesis (unverified)
The 10 s get_protocol_info deadline is tight for a cold host start on a loaded macos-latest runner. #3054 fixed a different race in the same test (pid liveness at exit-pipe close).
Acceptance
- No timing-only failures across repeated macos-latest runs of the job (e.g. 10 consecutive green runs).
- A host that never answers fails with a clear startup-timeout message, and cleanup does not mask it.
Activity
code-yeongyu commentedon Oct 22, 2026
Recurred on
mainat fafcfee, CI run https://github.com/code-yeongyu/senpi/actions/runs/39754103857, jobmacOS combined, step "Supervisor owner, normal-stop and compiler regressions" (2 failed, 26 passed):3044-rpc-owner-lifetime.test.ts > exits within the bound after owner normal exit:spawned RPC socket host did not answer get_protocol_info within 10000ms, then cleanup'srefusing changed process.3045-owner-review.test.ts > starts an unowned host without opening an owner watcher even when watches are exhausted:missing readyafter 20 s.Same symptom as this issue. The neighbouring
mainCI runs passed this step on macOS: 811267c (08:51Z), c2f7c6f (10:16Z), 2f4501b (10:32Z). The fafcfee change (#3951, frontier stable prefix) does not touch RPC host code.code-yeongyu commentedon Oct 27, 2026
Another occurrence on the 'macOS combined' check (macos-26-arm64 hosted runner) for #4374 at 6e92045 (merge ref 3a7c135): test/suite/regressions/3044-rpc-owner-lifetime.test.ts > RPC owner lifetime > does not exit early when live: "spawned RPC socket host did not answer get_protocol_info within 10000ms", followed by "refusing changed process" in cleanup. #4374 does not touch the RPC host, supervisor or owner-lifetime code; the same head passed 23,701/23,701 tests in a full local run. Job: https://github.com/code-yeongyu/senpi/actions/runs/40431984015/job/121951674535
code-yeongyu commentedon Oct 27, 2026
Another occurrence, local Linux/macOS review run of senpi#4374 at 45f7408 (a merge of main into the PR; the delta touches neither the RPC host nor its startup path):
test/suite/regressions/3044-rpc-owner-lifetime.test.ts:55failed once with "spawned RPC socket host did not answer get_protocol_info within 10000ms" while the host's load average was ~40 on 18 cores; the same file passed 8/8 when re-run alone right after. Same load-sensitive 10 s deadline.Merge pull request #4526 from code-yeongyu/feat/engine-trust-marker