Skip to content

Commit 708ea5d

Browse files
ufukaltinokualtinok
authored andcommitted
test(e2e): wait for terminal historian state (flag cleared), not just compartment row
historian-success failed in CI (host behavior) at line 216: compartment published (count=1) and historian ran (requests=1), but compartment_in_progress was still 1. Passed locally (44/44 on 1.16.0); only the slower CI runner hit it. Root cause is a test race, not a plugin bug. The compartment row is COMMITted (compartment-runner-incremental.ts BEGIN IMMEDIATE..COMMIT) well before compartment_in_progress clears at the end of the same async run — there's an (git/project registration, slower on a fresh CI checkout) plus embedding/signal/marker work in between. The old waitFor keyed only on compartment count, so it returned the instant the row appeared and then asserted the flag, which hadn't cleared yet. The flag always ends at 0 on a finished run (success path clears it; any throw clears it via the runner catch), so the terminal invariant is compartment
1 parent ab8e203 commit 708ea5d

1 file changed

Lines changed: 21 additions & 3 deletions

File tree

packages/e2e-tests/tests/historian-success.test.ts

Lines changed: 21 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -173,7 +173,18 @@ describe("historian success path", () => {
173173
// in v0.14.1, tests need to provide the follow-up turn explicitly.
174174
await h.sendPrompt(sessionId, "turn 12: post-trigger follow-up.");
175175

176-
// Wait for historian to publish at least one compartment.
176+
// Wait for the historian run to REACH ITS TERMINAL STATE: at least
177+
// one compartment published AND compartment_in_progress cleared.
178+
// These are NOT simultaneous — the compartment row is COMMITted
179+
// (compartment-runner-incremental.ts BEGIN IMMEDIATE..COMMIT) well
180+
// before the flag clears at the end of the same async run, with an
181+
// `await ensureProjectRegistered` + embedding/signal/marker work in
182+
// between. Waiting only on the compartment count (the old check)
183+
// raced that window: on a slower runner the row exists while the
184+
// flag is still 1. The flag always ends at 0 on a finished run
185+
// (success path clears it; any throw clears it via the runner's
186+
// catch), so the terminal invariant is "compartment present AND flag
187+
// cleared". Wait for both.
177188
await h.waitFor(
178189
() => {
179190
const row = h
@@ -182,9 +193,16 @@ describe("historian success path", () => {
182193
"SELECT COUNT(*) as c FROM compartments WHERE session_id = ?",
183194
)
184195
.get(sessionId) as { c: number } | null;
185-
return (row?.c ?? 0) >= 1;
196+
if ((row?.c ?? 0) < 1) return false;
197+
const meta = h
198+
.contextDb()
199+
.prepare(
200+
"SELECT compartment_in_progress FROM session_meta WHERE session_id = ?",
201+
)
202+
.get(sessionId) as { compartment_in_progress: number } | null;
203+
return (meta?.compartment_in_progress ?? 1) === 0;
186204
},
187-
{ timeoutMs: 30_000, label: "compartment row appears" },
205+
{ timeoutMs: 30_000, label: "compartment published and in-progress flag cleared" },
188206
);
189207

190208
// Assertions.

0 commit comments

Comments
 (0)