Repository navigation
🧪 Flake: REPL lifecycle L2 samples Elicit:enter instead of Elicit:active:question in multi-file selections #935
Description
packages/cli/tests/repl-lifecycle.test.ts:130, row L2: an element waiting on
a question says so, and stops when it is answered, intermittently samples the
wrong lifecycle phase. The identical revision passes on a re-run with no fix, so
this is the flake record AGENTS.md asks for rather than a repair.
What it reports
error: Error: expect(received).toEqual(expected) // deep equality
Array [
- "Elicit:active:question",
+ "Elicit:enter:",
]
).toEqual(["Elicit:active:question"]);
at packages/cli/tests/repl-lifecycle.test.ts:130:7
Evidence of intermittence
| When | Runtime | Command | Outcome |
|---|---|---|---|
2026-10-14, at 10b17a40 |
Deno, local | deno task test packages/cli/tests/repl-execution.test.ts packages/cli/tests/repl-lifecycle.test.ts |
5 tests / 38 steps, L2 failed |
| same | Deno, local | the file alone | 1 test / 8 steps, passed |
| same | Deno, local | the identical two-file command, nothing changed | 6 tests / 39 steps, passed |
| 2026-10-16, at #883 PR2 integration head | Deno, local | deno task test packages/cli/tests/repl-route.test.ts packages/cli/tests/repl-layout-admission.test.ts packages/cli/tests/repl-presentation-style.test.ts packages/cli/tests/repl-source-reading.test.ts packages/cli/tests/repl-execution.test.ts packages/cli/tests/repl-lifecycle.test.ts |
45 passed (189 steps), L2 failed |
| same | Deno, local | the identical six-file command, nothing changed | 46 passed (190 steps), passed |
Both failures are in a multi-file selection; the file alone has not been seen
to fail. CI has not reported it on #890 or #921.
Where to look
The row samples the lifecycle reading after a fixed number of sleep(0) yields,
so the phase it observes depends on how much work the runner has queued ahead of
it. Elicit:enter: is the phase immediately before Elicit:active:question,
which is consistent with sampling one scheduler turn too early when another
suite's work is interleaved.
That names the readiness assumption to investigate. It is not a proven cause,
and it is not a licence to change the assertion or the yield count: the row's
claim — that an element waiting on a question says so — is the right claim.
Why this is open
A green re-run restored the command's health and does not close this. Closing it
needs a cause and discriminating evidence, per AGENTS.md.
Earlier local record: .reviewer/issue-883/pr2-repl-lifecycle-l2-flake-10b17a40.md.
Sibling flake: #874.
Delivery audit — 2026-10-31
The owner comment records the timing cause and a discriminating old-wait control. Merged #981 replaces sampling with actual question readiness and adds a held-import regression while preserving complete lifecycle assertions.
Existing implementation and regression evidence: packages/cli/tests/repl-lifecycle.test.ts. This audit reuses the recorded evidence and inspects merged source; it runs no new tests or model calls.
Activity
🚨 Wait for the phase L2 is about instead of sampling after five turns (…
taras commentedon Oct 17, 2026
Cause found and fixed
This failed CI on #921 (
test-deno (6/15), run 38989066578) and was the singleremaining failing check, so it was repaired at the cause rather than re-run.
The boundary. The row sampled
session.lifecycle.occurrencesafter a fixedfive
sleep(0)turns. The phases a consumer is told travel through their ownqueue, and the question is published from inside the element, so how many turns
that takes depends on what else the runner has queued. With another suite beside
it the sample lands on
Elicit:enter:— the phase immediately before the onethe row is about — which is exactly the reported diff.
The fix. It now waits for a signal deliberately narrower than its claim:
that some element has reported waiting on something. Which element, which
phase, what it waits on, and that it is the only one are all still asserted
whole, so a wrong phase or a second waiting element still fails. A wait for the
expected value would have asserted nothing.
Discriminating evidence, same revision either way, only that loop differing:
The sibling fixed-turn loop below it keeps its count: that one asserts the
reading stays empty, where more turns only strengthen the claim.
Intermittency means the passing runs are supporting evidence rather than proof.
The case rests on the cause above plus the control, which reproduces the failure
with only that loop changed back.
Carried in #883's delivery of #921.