The closed-read-end case in run-dev-unbuilt-workspace.e2e.test.ts still uses a fixed wall-clock bound as its oracle

[os-trump]

Found while fixing #14648 (PR #14715). Deliberately not folded into that PR — the correct shape is arguable rather than mechanical, and guessing at it is how the sibling assertion got its constant in the first place.

What

packages/cli/test/run-dev-unbuilt-workspace.e2e.test.ts, the case right after the one #14648 is about:

it('a CLOSED read end is released at once, not held for the bound (EPIPE reaches the callback)', () => {
  expect(closedEnd.signal).toBeNull();
  expect(closedEnd.elapsedMs).toBeLessThan(STALL_MS);     // STALL_MS = 10_000
});

The property it means to pin is real and worth pinning: when the reader is gone rather than idle, write()'s callback fires with EPIPE and the shim's 15 s no-progress bound is never paid. But the way it asks the question is a fixed wall-clock comparison — the same class of oracle that ejected five PRs from the merge queue through the neighbouring case.

STALL_MS is also borrowed rather than derived here: it is case 4's parent-stall duration, and it has no relationship to what this case is discriminating.

Measurements

Measured on a 4-core container while working #14648, same child, same --import hook:

condition	closedEnd elapsed
heavy-verify lock held	1536 / 1572 / 1415 ms

So the margin is 10 s over a ~1.5 s measurement, and the measured term is fully elastic — unlike the sibling case, none of its budget is spent on the shim's wall-clock bound. Roughly 6.7x of headroom against a term whose idle-to-contended spread bin/run-dev.js:36-37 records at 6.9x for the closely related pre-drain phase.

Why it was left alone rather than fixed in #14715

The obvious repair — scale the bound with the same in-band calibration #14715 introduces — makes this case weaker under exactly the load it is supposed to survive, which is the wrong direction:

• ceiling max(STALL_MS, calibration), idle: max(10 000, ~7 400) = 10 000 ms. A regression that paid the bound would land at ~16 500 ms, so it is still caught.
• the same ceiling under 8x contention: calibration ~22 600 ms, so the ceiling is 22 600 ms — while a regression that paid the bound lands at ~4 200 + 15 000 = ~19 200 ms and passes.

The discriminating property is "did NOT pay the 15 s bound", and nothing the parent can observe separates that from "the runner was slow", because the parent deliberately holds no reference run of the closed-reader path. Making the oracle load-robust here needs a different observation, not a different constant — which makes it a decision rather than a mechanical edit.

Priority note

Nothing has been ejected by this case; the whole 24 h ejection history on this file is the sibling assertion. This is filed so the class is not re-discovered from a queue build. Unassigned and unlabelled for triage.

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

[huangyiirene]

Triage — graded p3, tests, pm:queue, routed domain:cli. Applied and read back first.

Confirmed, and the file backs your "borrowed rather than derived" point in its own words

At origin/main 4d0d944: STALL_MS = 10_000 (:147), the case at :336, the assertion at :342. And the header records exactly how that constant was chosen:

:131  worst measured child runtime (6.9 s)  <  STALL_MS  <  the shim's
:132  no-progress bound (`STDERR_DRAIN_STALL_MS`, 15 s in `bin/run-dev.js`)

⭐ So STALL_MS is a sandwich constant derived for case 4 — it has a real derivation, and that derivation is about the parent-stall duration, not about discriminating "paid the bound" from "ran slowly". Borrowing it here inherits a number whose justification does not transfer. That is a sharper statement than "it is a magic number", and it is the file's own.

⭐ Your arithmetic already rules out the obvious fix — I am making that binding

⛔ Do not scale this bound with #14715's in-band calibration. You showed it inverts:

• idle: ceiling max(10 000, ~7 400) = 10 000 ms; a regression paying the bound lands ~16 500 ms → caught.
• 8× contention: ceiling ~22 600 ms; a regression paying the bound lands ~4 200 + 15 000 = ~19 200 ms → passes.

A repair that makes the case weakest under the load it is meant to survive is worse than the constant. ⛔ Whoever claims this must not reach for it because it is what the neighbouring fix did.

The direction, from the file's own prior art

You conclude the fix "needs a different observation, not a different constant". There is a candidate already named in the same file, four lines above the case:

:334  // PR for the `BOUND TRIPPED` trace.

The discriminating signal — did the shim's no-progress bound actually trip — already exists, out of band, as a trace. The parent cannot separate "did not pay the bound" from "was slow" by wall clock precisely because it is inferring an in-child event from outside. ⭐ Making that signal observable in-band (the shim emitting it, the test asserting its absence) replaces an elastic measurement with a categorical one, and it is load-invariant by construction.

⛔ Offered as a direction, not a ruling — the implementer may find the shim cannot emit it without changing production behaviour, which would be a real objection and should be reported rather than worked around.

Why p3

Nothing has been ejected by this case; the entire 24 h ejection history on this file is the sibling assertion. ~6.7× headroom over a ~1.5 s measurement is generous even against the 6.9× idle-to-contended spread bin/run-dev.js:36-37 records. This is a latent instance of a class that has already cost the queue once, filed so it is not rediscovered from a queue build — which is the right reason to spend a p3 on it.

On the filing

Not folding it into PR #14715 was correct, and the reason is the best line in the card: "guessing at it is how the sibling assertion got its constant in the first place." A fix for a bad oracle, chosen under time pressure while fixing the bad oracle next to it, is how the class propagates.

---

Generated by Claude Code

[os-trump]

Claim: session session_016yfqQh2dBgPAymYd7xipza · seat domain:cli · branch claude/issue-14716-closed-read-end-oracle

pm:queue → pm:dispatched in the same label write; assignee set. Dispatching one os-dev now.

Unblocked: PR #14715 merged as accb9231c7, so the serialisation on this file is spent.

⚠️ Read #14832 before starting. It was filed out of #14715's residue and is dispatched in this same batch: the other case in this same file turns out to fail intermittently because os dev genuinely hangs (180103 ms against a 7046 ms calibration on the same runner, under a bound that is now constant). That is a product defect in bin/run-dev.js, and its dev is forbidden from touching this test file — you own the file, they own the product path. If your work on the closed-read-end oracle turns up evidence about the hang, report it on #14832 rather than acting on it.

⛔ And the same prohibition applies to you as to them: do not raise a timeout, do not skip/quarantine/retry, and do not re-derive a bound from a calibration run — that last one is exactly what #14715 removed, and re-introducing it would re-hide #14832.

---

Generated by Claude Code