test(ts): fix flaky subscribeToEvents (race + block-time-dependent window)#4059
Merged
Conversation
…ndow) subscribeToEvents only watched *future* heads for up to 30 blocks. Callers typically `await` the triggering extrinsic (tx.wait() resolves once mined) *before* subscribing, so the event is often already in a past block — the watcher then scans 30 empty blocks and times out. The 30-block budget also silently halved in wall-clock terms when block time dropped 12s -> 6s, making the omniBridge.PaidIn / vesting.VestingCompleted assertions flaky in CI. Scan a window of recent blocks back from the current head first (catches the already-emitted event), then fall back to a forward watch bounded by wall-clock time (180s) instead of a fixed block count, so it no longer shrinks with block time. Settle-once guard avoids double resolve/reject.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
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
heimazombienet ts-test job has been intermittently failing with:(seen on #4057 and #4058, both unrelated to their actual changes —
paseo, which runs the same suite, passes). Two root causes insubscribeToEvents:await executeTransaction(...)— which resolves once the EVM tx is mined — and only then callsubscribeToEvents. The helper only watched futuresubscribeNewHeads, so the event was frequently already in a past block. It then scanned 30 empty blocks and rejected. (Passing at all was luck — subscription registering near the event's block boundary.)blocksToScan = 30. At 12s that was ~6 min; after the 12s→6s upgrade it silently became ~3 min — so the same test got tighter for no logical reason, making the flake more frequent.Affected call sites:
precompile-contract.test.tsomniBridge.PaidInandvesting.VestingCompleted(latter merely got lucky).Fix
subscribeToEventsnow:LOOKBACK_BLOCKS(10) from the current head and returns immediately if the event already landed — kills the race without touching call sites.FORWARD_TIMEOUT_MS = 180s) instead of a block count, so the window no longer shrinks with block time.No call-site changes required; signature unchanged.
Verification
tsc --noEmitclean for the changed file.heimats-test job exercises both affected events end-to-end in CI.