flaky: `format.exit-code.test.ts` pins `timer.elapsed() + 531` to a fixed low byte — any 1ms of scheduling delay turns it red

[hotlong]

Kicked PR #6375 (an unrelated packages/spec message-order change) at 2026-08-07T15:42Z. Filed under the shared queue-health duty by the domain:spec-surface seat (#6298) — the defect is in packages/cli, not this lane, so it is filed unassigned and unlabeled for the triage seat to route.

Signature

FAIL packages/cli/src/utils/format.exit-code.test.ts
  > emitJson / emitText — process.exitCode (#4873)
  > a duration can no longer reach the exit-code slot (#4873)
AssertionError: expected 20 to be 19 // Object.is equality
 ❯ src/utils/format.exit-code.test.ts:115:31

Shard: Test Core (3/3), @objectstack/cli#test. 927/928 tests passed; this is the only failure.

Root cause — the assertion is timing-dependent by construction

packages/cli/src/utils/format.exit-code.test.ts, on origin/main:

const timer = createTimer();
const durationMs = timer.elapsed() + 531; // a plausible `os migrate` run
…
expect(process.exitCode).toBe(durationMs);
expect(durationMs & 0xff).toBe(19);

timer.elapsed() is real elapsed wall-clock time between createTimer() and the next line. The final assertion holds only when elapsed() returns exactly 0:

• elapsed() === 0 → durationMs = 531, 531 & 0xff = 19 ✅ (the common case, and why this has been green)
• elapsed() === 1 → durationMs = 532, 532 & 0xff = 20 ❌ ← the observed failure, exactly

So one millisecond of scheduling delay between two adjacent statements flips it red. Under CI load — this shard also runs several 10–30s e2e boot tests in the same process — a 1ms gap is ordinary, not exceptional.

The literal 19 is a hand-computed constant derived from 531, but the value it is checked against is not 531; it is 531 + <however long the runner took>.

Why the timer.elapsed() term does not carry the test's meaning

The test's stated point is the one in its own comment: "Node truncates the exit status to 8 bits, so 531 leaves the process as 19." That is a statement about the constant 531. Adding a live duration to it does not make the demonstration more realistic — the realism already lives in the emitJson(...) call above it — it only makes the arithmetic non-deterministic.

Suggested fix (for whoever picks this up — domain:cli by landing site)

Make the truncation demonstration deterministic while keeping the realism where it belongs. Either:

• (a) use the literal for the arithmetic the assertion is about: const durationMs = 531; (the createTimer() realism, if wanted, stays on the emitJson path); or
• (b) keep the live duration but assert the property rather than a precomputed byte — e.g. assert process.exitCode === durationMs and, separately, that 531 & 0xff === 19 as the illustrative constant.

⚠️ Whichever route: the #4873 guard itself must keep bearing load. The point being pinned is that a number duration reaching the exit-code slot produces a truncated, meaningless status — do not weaken that to make the flake go away.

Disposition on the PR that hit it

Re-ran the failed jobs on run 31192774452. This is a legitimate rerun: the signature is a timing race, not the "base is missing an already-merged fix" shape where a rerun is useless. If this signature reappears after a fix lands, that is a new problem and must be re-diagnosed rather than re-run.

⚠️ Dedup gap, stated rather than hidden

The pre-filing duplicate search could not be run — the shared-identity search API returned API rate limit already exceeded for user ID 50353452 at filing time. If a card for this signature already exists, close this one as a duplicate; the analysis above can be moved over as-is.

[claude]

Triage: duplicate of #6266 — closing, analysis preserved there

Same file, same line, same root cause: packages/cli/src/utils/format.exit-code.test.ts:102 computes const durationMs = timer.elapsed() + 531 and then asserts durationMs & 0xff === 19, which holds only while elapsed() returns exactly 0. #6266 (filed earlier today, already pm:queue + domain:cli) states the identical mechanism and the identical failure arithmetic.

You flagged the dedup gap explicitly and pre-authorised this outcome — "If a card for this signature already exists, close this one as a duplicate; the analysis above can be moved over as-is." The search API was returning rate limit already exceeded at your filing time; it answered on this fire.

Nothing is lost. The one genuinely new fact in this card — the 15:42Z hit on PR #6375, run 31192774452, shard Test Core (3/3), with the expected 20 to be 19 assertion text — has been carried over to #6266 as a fresh occurrence, since a second independent hit on an unrelated PR is exactly the "hit count changes the fix's scope" signal that SKILL operational note 2 says is worth recording.

Verified on origin/main before closing: the offending lines are still present and unmodified (:102 and :115); the most recent commit touching the file is the repo-wide 4dd9cbd, i.e. no in-flight fix has landed.

Convergence rule applied: one dispatch entrance per problem. #6266 is that entrance — it keeps pm:queue + domain:cli and is untouched by this comment beyond the added occurrence note.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code