Skip to content

test(the-framework): make the re-home failure say why#1166

Merged
suleimansh merged 1 commit into
mainfrom
test/1165-rehome-diagnostic
Jul 25, 2026
Merged

test(the-framework): make the re-home failure say why#1166
suleimansh merged 1 commit into
mainfrom
test/1165-rehome-diagnostic

Conversation

@suleimansh

Copy link
Copy Markdown
Member

Part of #1165.

The CI-only failure of the #1122 re-home test is a bare 1 !== 2. The reason is already on disk — a failed re-home records could not re-home this run: <reason> in the scratch events log and retains the scratch — so the test now reads both when the second spawn is missing.

Why this rather than another budget bump: the passing case takes 367ms and every failure burns the entire poll budget (6s, then 15s, then 30s at which point the file hit the 60s per-test cap). It is binary — the re-home happens at once or not at all — so no budget will ever fix it, and my earlier #1153/#1154 framing of it as a slow runner was wrong.

1286 tests green locally. Test-only, no changeset.

The CI-only failure of this test is a bare `1 !== 2`, which says only that the
daemon did not spawn the continued run. The reason is already on disk: a failed
re-home is recorded as an event in the scratch log, and the scratch is retained
rather than removed.

Read both when the second spawn is missing, so the next occurrence names the
cause instead of costing another round of guessing. The passing case takes
~370ms, so a run that burns the whole poll budget has not been slow.

Part of #1165
@suleimansh suleimansh added bug Something isn't working priority: medium Worth doing, not urgent the-framework ♻️ labels Jul 25, 2026
@suleimansh suleimansh self-assigned this Jul 25, 2026
@suleimansh
suleimansh marked this pull request as ready for review July 25, 2026 14:19
@suleimansh
suleimansh merged commit c4e5d4c into main Jul 25, 2026
1 check failed
@suleimansh
suleimansh deleted the test/1165-rehome-diagnostic branch July 25, 2026 14:19
suleimansh added a commit that referenced this pull request Jul 25, 2026
The #1122 re-home test seeded the bind the instant `onStart` returned, so the
re-home it triggers could terminate a child that had not finished booting. On a
loaded runner that SIGTERM landed before the stub recorded its argv, and the run
looked like it never spawned: a bare `1 !== 2` after the whole poll budget.

A real bind cannot arrive that early. The run writes it into its own event log
(`recordBind`, cli.ts), so a bind the daemon sees always comes from a process
that is already running. The test now waits for that start before binding.

Also: the stub installs its SIGTERM handler before its first write, so a signal
in between cannot take the default disposition and kill it silently; the #1166
diagnostic prints the recorded starts, since "which spawn is missing" was the
first question it could not answer; and the poll ceiling drops to 10s, which is
a backstop rather than a slowness allowance -- 6s, 30s and 15s all failed the
same way, because the re-home either lands in under a second or has gone wrong.

Closes #1165
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working priority: medium Worth doing, not urgent the-framework ♻️

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant