fix: process all batch pegout members when one is missing from the db - #482
Open
ronaldsg20 wants to merge 1 commit into
Open
fix: process all batch pegout members when one is missing from the db#482ronaldsg20 wants to merge 1 commit into
ronaldsg20 wants to merge 1 commit into
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Files |
ronaldsg20
marked this pull request as ready for review
September 10, 2026 17:30
processBatchPegouts walks the releaseRskTxHashes concatenation from a batch_pegout_created event and hit `break` as soon as a member had no matching record. Every remaining member of that batch was silently abandoned, including members that were present in the db. This triggers whenever a batch straddles the daemon's sync start block: requests made before the anchor were never indexed, so the first of them aborts the loop. Observed on mainnet batch 0x76d01052...627e65 (block 9219132), whose members 0 and 1 predate anchor 9216715. Members 2, 3 and 4 were left stuck at RECEIVED indefinitely even though the daemon had synced well past every later stage of their lifecycle. Skip only the missing member instead. The index still has to advance, because it maps to the btc tx output index — leaving it in place would misalign batchPegoutIndex and the generated rskTxHash key. Log the batch size and a matched/skipped tally around the loop so an incomplete walk is visible without enabling debug logging. Add a regression test built from the five real members of that mainnet batch, asserting that all members are visited, that only those found are written, and that the surviving pegouts keep indices 2, 3 and 4. Point .env.test at the current testnet blockbook host so CI matches the updated assertion in btc-last-block.service.unit.ts. The workflow copies .env.test over .env before running the suite, so the stale blockbook-01 hostname failed the pipeline. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ronaldsg20
force-pushed
the
fix/daemon-sync
branch
from
September 10, 2026 17:36
57f05ff to
17dd2b7
Compare
lserra-iov
reviewed
Sep 11, 2026
lserra-iov
left a comment
lserra-iov
left a comment
Contributor
There was a problem hiding this comment.
How can a member end up without a matching record? The description blames the daemon's sync start block, but was actually the daemon behind at that point? What happens with those pegouts, are the statuses processed correctly? I think this is an improvement, but I'm afraid it might not fix the root cause of the reported issue.
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.
processBatchPegouts walks the releaseRskTxHashes concatenation from a batch_pegout_created event and hit
breakas soon as a member had no matching record. Every remaining member of that batch was silently abandoned, including members that were present in the db.This triggers whenever a batch straddles the daemon's sync start block: requests made before the anchor were never indexed, so the first of them aborts the loop. Observed on mainnet batch 0x76d01052...627e65 (block 9219132), whose members 0 and 1 predate anchor 9216715. Members 2, 3 and 4 were left stuck at RECEIVED indefinitely even though the daemon had synced well past every later stage of their lifecycle.
Skip only the missing member instead. The index still has to advance, because it maps to the btc tx output index — leaving it in place would misalign batchPegoutIndex and the generated rskTxHash key.
Log the batch size and a matched/skipped tally around the loop so an incomplete walk is visible without enabling debug logging.
Add a regression test built from the five real members of that mainnet batch, asserting that all members are visited, that only those found are written, and that the surviving pegouts keep indices 2, 3 and 4.