test(runtime): add the #3259 flake canary (nested writes stay green at the stock 250ms CPU budget under load)#3351
Merged
Conversation
…at the stock 250ms CPU budget under load The verification "flake canary" from the ADR-0102 plan (#3275). It drives the real nested-write scenario (child afterInsert -> nested parent.update -> the parent's own hook = a second re-entrant VM) across 128 chains CONCURRENTLY through one shared stock runner, and asserts every invocation lands the correct rollup with zero CPU-budget / wall-ceiling errors at the stock 250ms budget. Closes the loop on ADR-0102 D1. #3259 was a LOAD flake: under the old wall-clock budget, the time an invocation spent parked at an `await` while other concurrent invocations ran was charged to it, so it blew 250ms under oversubscription even though its own VM did microseconds of work. D1 charges script CPU-time only, so parked time is not counted. Validated as a real regression gate, not a no-op: temporarily reverting the interrupt handler to a `Date.now() - start` wall budget turns this suite RED from ~64 concurrent chains up, while the shipped CPU budget stays green through 256. It is robust (not itself flaky) because concurrency stresses the parked-time accounting D1 excludes, not slice size — the charged CPU per tiny rollup body is invariant to how many chains are in flight. `OS_CANARY_CONCURRENCY` overrides the default for an ad-hoc heavier soak. Test-only; no changeset. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011iJLjqToxNv1aYP3syQtRp
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 17 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
os-zhuang
marked this pull request as ready for review
July 20, 2026 07:45
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
2 participants
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.
The verification flake canary from the ADR-0102 plan (#3275) — the last item on that issue's checklist. #3275 is now closed; this ships the canary as a small test-only follow-up.
What it does
Drives the real nested-write scenario (child
afterInsert→ nestedparent.update→ the parent's own hook = a second re-entrant sandbox VM) across 128 chains concurrently through one shared stockQuickJSScriptRunner(250ms CPU budget), and asserts every invocation lands the correct rollup with zero CPU-budget / wall-ceiling errors.Why it matters (ADR-0102 D1)
#3259 was a load flake, not a logic bug: under the old wall-clock budget, the time an invocation spent parked at an
awaitwhile other concurrent invocations ran was charged to it, so it blew 250ms under oversubscription even though its own VM did microseconds of work. D1 made the budget script CPU-time, so parked time isn't counted — this canary is the end-to-end proof that the fix holds under concurrency.It's a real gate, and it's robust
Validated in both directions during development:
Date.now() - startwall budget turns this suite RED from ~64 concurrent chains up → it genuinely catches a D1 regression.It can't flake on its own because concurrency stresses the parked-time accounting D1 excludes, not slice size: the charged CPU per tiny rollup body is invariant to how many chains are in flight (JS runs each synchronous slice to completion, so concurrent chains interleave only between slices, at
awaitpoints).OS_CANARY_CONCURRENCYoverrides the default for an ad-hoc heavier soak.Notes
allow-majorbypasses the unrelated pre-existing@objectstack/console: majorchangeset already onmain.🤖 Generated with Claude Code
https://claude.ai/code/session_011iJLjqToxNv1aYP3syQtRp
Generated by Claude Code