Test: packages/workbench/tests/overview.e2e.test.ts > offers the host-owned MCP playground handoff only after a selected Runtime App succeeds
Evidence: CI run 33557117407 — Verify (Node 24) failed with AssertionError: expected 3 to be less than or equal to 2 at expectMonotonicOwnedReloadFrames (overview.e2e.test.ts:425), while Verify (Node 22.19.0) and Verify (Node 26) passed the identical commit in the same run. No other occurrence in today's main history.
Analysis: the test edits two watched sources and bounds the owned reload channel at ownedReloadGenerationBudget = 2 generations. The test's own comment documents that multi-compiler watch delivery skews under load ("one coalesced or two split App generations"). On a loaded 4-core hosted runner one edit's fs events can split into an extra rebuild, producing generation 3 — the same chokidar/watch-delivery load-skew class tracked in #122. The monotonicity proof (violations must be empty) still passed; only the ceiling was exceeded, so this was an extra legitimate rebuild, not a reload loop.
Interim treatment: per-test { retry: 2 }, matching the #138 treatment of the #122 family, so a bounded race does not hold the post-merge safety net red. Removing the retry requires either deterministic coalescing of watch delivery or deriving the budget from observed compile batches.
Test:
packages/workbench/tests/overview.e2e.test.ts > offers the host-owned MCP playground handoff only after a selected Runtime App succeedsEvidence: CI run 33557117407 — Verify (Node 24) failed with
AssertionError: expected 3 to be less than or equal to 2atexpectMonotonicOwnedReloadFrames(overview.e2e.test.ts:425), while Verify (Node 22.19.0) and Verify (Node 26) passed the identical commit in the same run. No other occurrence in today's main history.Analysis: the test edits two watched sources and bounds the owned reload channel at
ownedReloadGenerationBudget = 2generations. The test's own comment documents that multi-compiler watch delivery skews under load ("one coalesced or two split App generations"). On a loaded 4-core hosted runner one edit's fs events can split into an extra rebuild, producing generation 3 — the same chokidar/watch-delivery load-skew class tracked in #122. The monotonicity proof (violations must be empty) still passed; only the ceiling was exceeded, so this was an extra legitimate rebuild, not a reload loop.Interim treatment: per-test
{ retry: 2 }, matching the #138 treatment of the #122 family, so a bounded race does not hold the post-merge safety net red. Removing the retry requires either deterministic coalescing of watch delivery or deriving the budget from observed compile batches.