Repository navigation
Conversation
…hare The sustained sequential operations test ran 4200 operations, sized for the old 4096-entry replay table. Since #3281 one Sandbox meets its 2048-entry replay share first, so the table bound was no longer reachable from this test. Run REPLAY_SANDBOX_SHARE + 64 operations instead, and assert the premises: one horizon's entries fit under the share, the share is below the table, and the operation capacity is below the loop count. Mutants that skip replay pruning, the replay-share release, the operation-share release or the operation-capacity release still fail at operations 2048, 2048, 256 and 1024.
Contributor
|
🦞👀 Pull request received. I will update this pull request when review starts. |
Review nit: say that operation slots return on completion, or the loop stops at the operation share or capacity.
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
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.
Problem
The static-egress test "sustained sequential operations outlive replay capacity without waiting for JWT expiry" runs 4200 sequential operations. The literal was sized to pass the original 4096-entry replay table. Since #3281 the table holds 8192 entries and one Sandbox has a 2048-entry share, so a single Sandbox reaches its share long before the table. The test now guards the per-Sandbox replay share, not the table. It is also the slowest case in Checks and Conformance 1: usually 43-70 s in CI, and 93 s and 124 s on slow runners (180 s timeout).
Change
REPLAY_SANDBOX_SHARE + 64operations (2112), with the same 25 ms clock step.OPERATION_CAPACITYis below the loop count.Test-only change; the test name is unchanged, so the suite manifest is untouched.
Verification
Mutants of
packages/occ/src/credential-proxy.ts, run against the shortened test (Node 24, 2 CPUs):pruneReplayreturns at once (no replay expiry)releaseChargenever returns the Sandbox operation sharereleaseChargenever returnsactiveOperationsTiming:
taskset), before and after run concurrently, 4 rounds each: before 38.8-48.7 s (median 42 s), after 19.1-25.5 s (median 21 s).Pin: the whole file 20/20 at 2 CPUs (5 concurrent loops on separate CPU pairs; 78 tests per run, file 30-44 s, this case 19.9-29.3 s).
CI Required passed on 5ff8f1e; First Agent Smoke was skipped by the test-only path filter. An internal review approved with one comment nit, now applied.
Risks
Low; test-only. The shortened loop still runs 64 operations past the share, each of which needs an entry released by its horizon. Regressions that only show after many more horizons would not be caught, but no current bound depends on more than one share's worth of operations.