fix(test): eliminate race in Txn Expiration flaky test - #1459
Closed
kriszyp wants to merge 2 commits into
Closed
Conversation
The `assert.equal(trackedTxns.size, existingTxns)` assertion was flaky because other tests' open transactions can expire and be removed from the module-level set during the 50ms Promise.race window, causing the count to drop below the sampled baseline. Fix by checking whether the specific SlowResource transaction (already captured as `lastTxn`) was removed, rather than relying on the aggregate count staying stable. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates a transaction expiration unit test in txn-tracking.test.js to assert that a specific transaction was expired and removed, rather than asserting on the total size of tracked transactions, which was unreliable due to concurrent expirations. There are no review comments, so there is no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Contributor
|
Reviewed; no blockers found. |
Fixes the Format Check failure on this branch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
kriszyp
pushed a commit
that referenced
this pull request
Jun 23, 2026
The Slow txn will expire test asserted trackedTxns.size === existingTxns, where existingTxns was sampled before SlowResource.get. trackedTxns is a module-level singleton shared across the suite; leftover open txns from earlier tests can expire (removed by the 20ms timer) during the following 50ms Promise.race window, dropping the count below existingTxns (the 0 == 5 / 1 == 6 AssertionError seen in CI). This branch's added blob tests shift suite timing enough to make the latent flake deterministic. Assert membership of the specific txn from SlowResource.get(3) instead, which is immune to background txn churn. Identical to #1459. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Root cause
The
Slow txn will expiretest assertstrackedTxns.size === existingTxnsat the end, whereexistingTxnswas sampled before theSlowResource.getcall. The problem:trackedTxnsis a module-level singleton Set shared across the whole test suite. The 5 «existing» transactions sampled as the baseline are leftover open txns from earlier tests — and they can expire (and be removed from the Set by the 20ms timer) during the 50msPromise.racewindow that follows, causing the count to fall belowexistingTxns. This produces the0 == 5AssertionErrorseen on Node v26.The polling loop added to stabilize the baseline only checks for a 5ms quiet window; a txn whose countdown hits zero just after that window still fires in the next tick.
Fix
Replace the aggregate-count assertion with a direct membership check on
lastTxn— the specificDatabaseTransactionobject added bySlowResource.get(3). This is immune to other tests' txns expiring concurrently.Test plan
lastTxnreference was already captured unconditionally on line 52; only the final assertion changes🤖 Generated with Claude Code