bug(tests): wall-clock deadline assertion cancels all rdd-status-line tests in local full-suite runs #1157

Before submitting

• I searched open and closed issues and did not find a report of this problem.
• I reviewed this report and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem

Running the full test suite locally (node --experimental-strip-types --test tests/*.test.ts, or pnpm test) cancels all tests of tests/rdd-status-line.test.ts on a loaded machine, while CI stays green. This is pre-existing on main — reproduced on a pristine main checkout with no local changes — and invisible to CI because shared runners do not hit the same CPU contention.

Root cause: the deadline test below asserts wall-clock elapsed time under a stubbed never-settling reader. It measures machine responsiveness rather than code correctness, so any loaded local run breaks it, and a process-level cascade cancels the remaining tests of the file. The rest of the file already uses the right patterns (stubbed native reader, injected virtual clock in the memoization tests), so the fix is narrow: virtualize the timer in the deadline test or replace the elapsed bound with a structural assertion (did it resolve, without the underlying reader settling). The test protects an important invariant — a hung reviewMode read must never stall the session — so it should be made deterministic, not deleted.

I am volunteering to fix this if the issue is approved — happy to submit the PR.

Steps to reproduce

1. On a loaded Linux dev machine, from a clean checkout of main:

pnpm install --frozen-lockfile
node --experimental-strip-types --test tests/*.test.ts

2. Observe # fail 0 but # cancelled 10, with the first not ok being resolveRddModeStatus resolves to undefined within the deadline when reviewMode never settles, followed by the remaining tests of the same file cancelled.
3. Run the file in isolation:

node --experimental-strip-types --test tests/rdd-status-line.test.ts

It passes 7/7, both on main and on feature branches.

The wall-clock assertion in question (the neverSettling deadline test in tests/rdd-status-line.test.ts):

const neverSettling = fakeReviewMode(() => new Promise<never>(() => {}));
const deadlineMs = 150;
const status = await resolveRddModeStatus(neverSettling, "/repo-hung", AbortSignal.timeout(deadlineMs));
assert.ok(elapsed < deadlineMs + 1000, `expected the read to resolve near the ${deadlineMs}ms deadline, took ${elapsed}ms`);

Expected and actual behavior

Expected: the full suite is green locally exactly as on CI, with no test depending on wall-clock responsiveness.

Actual: the deadline test breaks its elapsed < deadlineMs + 1000 bound under load (the event loop is starved past ~1.15 s while dozens of test-file processes compete), and the runner cancels the remaining tests of the file — # pass 2628 / # fail 0 / # cancelled 10 on pristine main. Every developer who runs the full suite locally then has to spend time proving the cancellation was not caused by their own change.

gentle-pi version

From source: main @ 2b579c8 (also reproduced on the base of PR #1144, c3ae6fe).

Pi version

Pi coding agent 0.85.1 (the repo @earendil-works/pi-coding-agent devDependency).

Operating system

Linux

Relevant logs or error output (optional)

not ok 1301 - resolveRddModeStatus resolves to undefined within the deadline when reviewMode never settles
not ok 1302 - resolveRddModeStatus memoizes a resolved status per cwd for RDD_STATUS_MEMO_TTL_MS
not ok 1303 - resolveRddModeStatus re-reads once the memoized status expires
not ok 1304 - resolveRddModeStatus memoizes independently per cwd
not ok 1305 - resolveRddStatusLine renders on, off, and unavailable from the stubbed native reader
not ok 1306 - RDD_STATUS_TIMEOUT_MS is a small, positive bounded-deadline constant
not ok 1307 - getOrchestratorPrompt renders the resolved RDD status line next to the background policy line
not ok 1308 - getOrchestratorPrompt defaults to the worst-case unknown RDD status line (budget-critical path)
not ok 1309 - the prompt cache key distinguishes on, off, and unknown so each renders a distinct prompt
not ok 1310 - the on and off renders are never longer than the unknown (worst-case) render
# pass 2628
# fail 0
# cancelled 10