What it is
test/director-taste.test.ts > invitations (spec 14 §2.7/§5.10) > adds /feature-request at the session mark, from a one-shot timer times out on
loaded CI runners with Error: timed out waiting for the mark. Three
occurrences, on three different branches, including main itself:
Each time a plain rerun of the same commit passed. The main occurrence
pre-dates both PRs, so this is the test, not a change either of them made.
Cause (verified by reading, not by reproducing): the test arms
featureInviteAfterMs: 40 — a 40 ms one-shot timer — and then waits on
until(), whose budget is 200 × 5 ms ≈ 1 s (test/fakes.ts:412-419). There is
no slack between "the timer is late" and "the test fails": one scheduling stall
on a shared runner is enough. The two other suites seen timing out in the same
loaded runs (package.test.ts, tui-wave-image.test.ts, both green in
isolation) point the same way — runner contention, not logic.
Not yet investigated
- Whether
featureMark.unref() (src/director/director.ts, run()) contributes:
an unref'd timer is still serviced while the loop has other handles, but
nobody has checked its behaviour under a saturated event loop.
- Whether any other
until()-based director test is close enough to the same
budget to be the next one to go.
Spec
specs/spec14/14-listening-taste.md §2.7 / §5.10 — the invitation the test
covers. The behaviour is not in question here; only the test's timing margin.
Done when
The test no longer depends on a 40 ms timer landing inside a 1 s poll budget —
either the mark is given real slack or the wait is driven by the event rather
than by wall-clock — and the suite runs green across 20 consecutive CI runs with
no rerun. A change that cannot be shown to have removed the margin does not
close this.
What it is
test/director-taste.test.ts > invitations (spec 14 §2.7/§5.10) > adds /feature-request at the session mark, from a one-shot timertimes out onloaded CI runners with
Error: timed out waiting for the mark. Threeoccurrences, on three different branches, including
mainitself:mainzachg-0916--pick-prefetch-switching(#265)zachg-0917--pick-queue-depth2(#266)Each time a plain rerun of the same commit passed. The
mainoccurrencepre-dates both PRs, so this is the test, not a change either of them made.
Cause (verified by reading, not by reproducing): the test arms
featureInviteAfterMs: 40— a 40 ms one-shot timer — and then waits onuntil(), whose budget is200 × 5 ms ≈ 1 s(test/fakes.ts:412-419). There isno slack between "the timer is late" and "the test fails": one scheduling stall
on a shared runner is enough. The two other suites seen timing out in the same
loaded runs (
package.test.ts,tui-wave-image.test.ts, both green inisolation) point the same way — runner contention, not logic.
Not yet investigated
featureMark.unref()(src/director/director.ts,run()) contributes:an unref'd timer is still serviced while the loop has other handles, but
nobody has checked its behaviour under a saturated event loop.
until()-based director test is close enough to the samebudget to be the next one to go.
Spec
specs/spec14/14-listening-taste.md§2.7 / §5.10 — the invitation the testcovers. The behaviour is not in question here; only the test's timing margin.
Done when
The test no longer depends on a 40 ms timer landing inside a 1 s poll budget —
either the mark is given real slack or the wait is driven by the event rather
than by wall-clock — and the suite runs green across 20 consecutive CI runs with
no rerun. A change that cannot be shown to have removed the margin does not
close this.