flaky(runtime-host): owned Host lifecycle tests intermittently fail to observe process exit

[sunrioa]

Summary

Two owned Runtime Host lifecycle tests fail intermittently on a clean current main checkout, including during focused repetitions. Both tests assert that an owned process exits after its controlling lifetime ends.

The failures are nondeterministic: the same exact revision can pass, then fail on a later run without any source or environment change.

Environment

• Commit: 4ed6255f2998eff93414491cb14305f3bca0884b (main)
• OS: macOS 26.5.2, arm64
• Node.js: v24.19.0
• npm: 11.17.0
• Fresh detached worktree with a clean Git status
• npm ci: passed
• npm run build --workspace @maka/runtime-host: passed

Reproduction

Run the complete Runtime Host suite repeatedly:

npm run test:dist --workspace @maka/runtime-host

Then repeat the affected tests directly:

node --test \
  --test-name-pattern="an authority-supervised Candidate exits" \
  packages/runtime-host/dist/__tests__/host-kernel.test.js

node --test \
  --test-name-pattern="owned Host exits promptly after its first connection closes" \
  packages/runtime-host/dist/__tests__/owned-candidate.test.js

A serial full-suite control was also run with:

npm run test:dist --workspace @maka/runtime-host -- --test-concurrency=1

Results

Test mode	Result
Default-concurrency complete Runtime Host suite	2 passed / 3 failed across 5 runs
Focused authority-supervised Candidate exit test	8 passed / 2 failed across 10 runs
Focused owned Host first-disconnect exit test	9 passed / 1 failed across 10 runs
Serial complete Runtime Host suite	3 passed / 0 failed across 3 runs

The complete suite contains 1,687 tests: a green run reports 1,675 passed, 12 skipped, and 0 failed.

The default-concurrency failures moved between runs:

• Runs 2–4 failed an authority-supervised Candidate exits if its launch owner is killed.
• Runs 3–4 also failed owned Host exits promptly after its first connection closes.

The focused Candidate failure reports:

Error: process <pid> did not exit

The focused owned Host failure reaches its exit assertion with:

AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
false !== true

No process launched from the test worktree remained after the runs completed.

Impact

Unrelated pull requests can receive a blocking red Runtime Host result without modifying Runtime Host code. Because focused repetitions can also fail, this is not solely a full-suite concurrency artifact, although concurrent suite load appears to increase its frequency.

Related work

• test(runtime-host): investigate owned candidate connection flake #3190 recorded the earlier owned Host exits promptly after its first connection closes flake.
• fix(runtime-host): give owned-candidate connect a CI-safe election window #3221 was merged to give that specific owned-candidate connection path a CI-safe election window.

The current reproduction also covers the authority-supervised Candidate owner-death boundary, for which no matching Issue or PR was found.

Suggested investigation

• Determine whether the owned processes actually remain alive or whether the tests observe lifecycle state before settlement.
• Replace wall-clock timing assumptions with explicit lifecycle synchronization where practical.
• Preserve the existing ownership and process-exit assertions; avoid resolving the flake only through retries or weaker assertions.
• Verify any fix with repeated focused, default-concurrency, and serial suite runs.

Expected outcome

The affected tests deterministically observe the required process exit, and complete Runtime Host runs no longer fail because of scheduler-dependent lifecycle settlement.

AI assistance: OpenAI Codex assisted with reproduction, test triage, duplicate searching, and drafting this issue. The evidence and issue text were reviewed by me.

[UncertaintyDeterminesYou4ndMe]

I looked into this and closed my PR (#4784) to keep review load down while the project is slimming. Leaving the findings here so they are not lost.

• The launch-owner test gates its exit budget on connected.connection.closed, which is the Client's own transport: the Client aborts it after a 2 s unanswered liveness probe, so it resolves while a busy Host is still running. The owner-loss close is also only armed after composition startup and recovery settle (launchOwnerGuard.bind runs after startExecutionRuntimeHostCandidate resolves), and retryConnect connects while the Host is still recovering, so the SIGKILL lands mid-startup.
• The owned-exit test bounds the whole shutdown at 5 s while the kernel allows itself shutdownGraceMs (10 s); settle then SIGKILLs and reports an unclean exit.
• Neither test failed here in 42 focused and 19 full-suite runs; stalling the Host's main thread during startup and stalling composition close reproduce both reported errors exactly. Details and the proposed test-side fix are in test(runtime-host): assert owned Host exit against the kernel's shutdown contract #4784.
• The test that does flake on this machine is a different one, filed as flaky(runtime-host): WorkHub delegation races the automatic Session title through the candidate-set identity #4785.

[ggbdpq]

take