test: loosen gc dry-run lock-wait timing bound - #1041
Merged
Merged
Conversation
Windows CI shows a random 0.3 to 2.0 s scheduling stall in gc.test.ts, landing on a different EAS-sweep test each run. The dry run fail-fast assertion used a 500 ms bound, tight enough to fail once in 500 runs on that noise alone even though the timed code path cannot legitimately wait: EAS_LOCK_WAIT_MS is 0 for dry runs. A 5000 ms bound still catches a regression that made the dry run wait for withRemoteSessionLock 4 minute default, while clearing the observed worst-case stall.
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.
Description
Windows CI intermittently fails
gc.test.ts> "EAS orphan session sweep" >"dry run does not wait behind an active remote session creation lock",
which asserts the dry run returns in under 500 ms. It failed on
maininrun 36041519085 (job 107774581842) with an observed 1028 ms.
Across roughly 111 Windows runs,
gc.test.tsshows one random 0.3-2.0 sscheduling stall per run on
windows-latest, landing on a differentEAS-sweep test each time; tests that normally take 20-80 ms stall to
1.6-2.0 s. This assertion had failed only this once in 500 runs since
2026-09-11, consistent with runner noise rather than a product regression:
the timed code path cannot itself wait, since the dry run sets
EAS_LOCK_WAIT_MS = 0and fails fast on a held claim instead of waiting.Solution
Loosen the bound from 500 ms to 5,000 ms. That is still tight enough to
catch a real regression, where the dry run waits for
withRemoteSessionLock's 4-minute default instead of failing fast, whileclearing the 2.0 s worst-case stall observed on Windows CI.
Test plan
pnpm test packages/stim-cli/src/__tests__/gc.test.ts: 151 passed.pnpm run format:check,pnpm run lint,pnpm run typecheck,pnpm run knip: all pass.Closes #1040