render-smoke's under-the-deadline test is timing-marginal, and aborts the whole gate when it flakes

[cliffhall]

Summary

scripts/lib/render-smoke.test.mjs's case "a paint landing just under the deadline is not failed by the render timer" (added by #2147) leaves too little slack for process startup, so it fails intermittently under load — and because test:scripts is the 4th step in validate's && chain, a flake there aborts npm run local:gate before it reaches any client. Each occurrence costs a full re-run of the ~20-minute gate.

The margin

const paintAt = 250;
const r = await runRenderSmoke({
  ...stub(`setTimeout(() => { console.log(MARKER); … }, ${paintAt});`),
  timeoutMs: paintAt + 150,   // 400ms
  surviveMs: 400,
});

The stub is a real node -e child that paints 250ms after its own start, while the 400ms deadline runs from spawn. So the whole budget for spawn + Node boot + module init is 150ms. Node's cold start alone is routinely near or past that on a loaded machine.

Observed

Three failures in one session on an otherwise-idle-ish dev machine, two of them back to back:

✖ a paint landing just under the deadline is not failed by the render timer (416.44ms)
  AssertionError: expected pass, got: child did not render "MCP Servers" within 400ms
✖ … (407.93ms)   # same, next run

Both times it passes 3/3 immediately afterwards when run in isolation (node --test scripts/lib/render-smoke.test.mjs), which is what identifies it as a margin problem rather than a defect in runRenderSmoke.

Why not just raise the number

The tightness is deliberate and load-bearing — the comment says so: the render deadline has to expire while the survival window is still open, because that overlap is the bug being pinned. So the fix is not "make timeoutMs bigger"; it has to keep timeoutMs < surviveMs while stopping the child's startup from eating the render budget. Options worth weighing:

• Have the stub signal readiness and start its paint timer from a point the harness observes, so the measured interval excludes Node boot.
• Scale both numbers off a measured spawn baseline taken once per run.
• Inject a clock so the case is deterministic rather than wall-clock timed.

Acceptance

• The case pins the deadline-vs-survival-window overlap it was written for, without depending on process startup fitting in a fixed budget.
• It passes under concurrent load, not only on an idle machine.
• The other cases in the file keep their current meaning (forbidOutput, the exit-before-paint case, the survival assertions).

Found while running npm run local:gate for #2171.

[cliffhall]

Triage: Priority Medium (total 7)

• Severity 3 — nothing user-facing is broken, but the mandatory pre-push gate aborts before it reaches any client, so a real failure is masked and each occurrence costs a ~20-minute re-run
• Urgency 3 — wanted this milestone; it is in the path of every push
• Bonuses: +1 bug label

Not Urgent: it is a developer-workflow cost with an obvious workaround (re-run), not a product defect.

[cliffhall]

Correction — I mischaracterized the evidence

I wrote that this fails "on an otherwise-idle-ish dev machine." That was wrong, and it is the load-bearing claim in the report, so I am retracting it rather than leaving it to mislead whoever picks this up.

Checking the machine after a third failure: load average 60.10 / 88.69 / 82.25. Two other worktrees were running their own suites concurrently (a vitest --coverage unit+integration run, and a launcher vitest run). The same gate run that produced the 407ms failure also timed out an unrelated test — ServerSettingsModal > maps the OAuth insufficient-scope policy into settings (SEP-2350) — at the flat 5000ms vitest timeout, with 7190 other tests passing.

So the honest reading is: the machine was saturated, and this test failed first because it has the least slack — not because 150ms is wrong under normal conditions. On an unloaded machine node -e boots in well under that. A test that fails at load 60 alongside a 5-second timeout elsewhere is not evidence of a defect in this test.

What may still be worth something, stated without the bad evidence behind it:

• It is the most load-sensitive assertion in the repo, and it sits 4th in validate's && chain, so when the machine is busy it is the thing that aborts the gate before it reaches any client. That is a real cost, but it is a cost of running the gate under contention, which is a workflow problem rather than a test bug.

Recommend closing this as not planned unless it is seen failing on a quiet machine. I am leaving it open only so a maintainer makes that call rather than me quietly withdrawing a report I already filed and boarded.