Skip to content

perf(test): derive the sustained static-egress loop from the replay share - #3288

Merged
freeqaz merged 2 commits into
mainfrom
fix-2243
Oct 23, 2026
Merged

freeqaz merged 2 commits into
mainfrom
fix-2243

Conversation

@freeqaz

@freeqaz freeqaz commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

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

  • Derive the loop count from the exported constants: REPLAY_SANDBOX_SHARE + 64 operations (2112), with the same 25 ms clock step.
  • Assert the test's premises, so a later constant change cannot quietly make it vacuous:
    • one 30 s horizon of entries at that step (1200) fits under the share;
    • the share is below the table;
    • OPERATION_CAPACITY is below the loop count.
  • Add a comment naming which bounds the test exercises. The installation-wide table's expiry stays covered by "one Sandbox's replay share bounds it without refusing other Sandboxes".

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):

Mutant Result
pruneReplay returns at once (no replay expiry) fails at operation 2048
table entry deleted, Sandbox replay share never returned fails at operation 2048
releaseCharge never returns the Sandbox operation share fails at operation 256
releaseCharge never returns activeOperations fails at operation 1024
share returned, table entry never deleted passes this test before and after the change (4200 < 8192); fails "one Sandbox's replay share bounds it without refusing other Sandboxes"

Timing:

  • Local, 2 CPUs (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).
  • CI, Checks and Conformance 1 on this head: the case took 37.9 s and its file 54.5 s. The file no longer ends the lane: the last file ends at 66.8 s.
  • Latest main (9db4478): the case took 53.6 s, and the file ran 65.2 s and ended the lane at 68.1 s.
  • The slow main run on f2a5b4b: the case took 92.7 s, and the file ran 106.5 s and ended the lane at 110.1 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.

…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.
@clawsweeper

clawsweeper Bot commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

🦞👀
ClawSweeper picked this up.

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.
@freeqaz
freeqaz marked this pull request as ready for review October 23, 2026 09:08
@freeqaz
freeqaz requested a review from a team as a code owner October 23, 2026 09:08
@freeqaz
freeqaz merged commit 0082a15 into main Oct 23, 2026
25 of 27 checks passed
@freeqaz
freeqaz deleted the fix-2243 branch October 23, 2026 09:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant