Add bounded lookback window for deposit sweep event queries #3864
+229
−3
Conversation
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
…ries Add a configurable look-back period (DepositSweepLookBackBlocks = 216000 blocks, ~30 days) to FindDepositsToSweep so it only scans recent blocks for DepositRevealed events instead of the full chain history. When the current block exceeds the look-back window, filterStartBlock is computed as currentBlock - lookBackBlocks; otherwise it falls back to 0 to guard against underflow. FindDeposits (used by the MovingFunds safety guard) continues to scan from block 0 to preserve full-history coverage. Add tests for both the bounded lookback path (currentBlock=300000, filterStartBlock=84000) and the underflow guard path (currentBlock=100000, filterStartBlock=0). Wire MockBlockCounter into the existing JSON-driven scenario tests so they pass with the new BlockCounter dependency.
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.
Summary
FindDepositsToSweepnow limitsDepositRevealedevent scanning to the most recent ~30 days (DepositSweepLookBackBlocks = 216000blocks) instead of querying from block 0, significantly reducing RPC load on long-running nodescurrentBlock < 216000,filterStartBlockremains0to avoid uint64 wraparoundFindDeposits(used by the MovingFunds safety guard) continues to scan from block 0 to preserve full-history coverage for wallet safety checksChanges
Production code (
deposit_sweep.go):DepositSweepLookBackBlocksconstant (216000 blocks, ~30 days at 12s/block)filterStartBlockparameter to internalfindDeposits()functionFindDepositsToSweep()computes bounded start block viaBlockCounter.CurrentBlock()with underflow guardFindDeposits()passesfilterStartBlock=0to preserve full-history behaviorDepositRevealedEventFilter.StartBlockfrom the computed valueTests (
deposit_sweep_test.go):TestDepositSweepLookBackBlocks— validates the constant equals 216000TestDepositSweepTask_FindDepositsToSweep_BoundedLookback— exercises the bounded path withcurrentBlock=300000, producingfilterStartBlock=84000TestDepositSweepTask_FindDepositsToSweep_UnderflowGuard— exercises the underflow path withcurrentBlock=100000, keepingfilterStartBlock=0MockBlockCounterinto existing JSON-driven scenario tests to satisfy the newBlockCounterdependencyTest plan
go test ./pkg/tbtcpg/... -v— all 20 test functions pass (0.3s)go build ./pkg/tbtcpg/...— compiles cleanlygo vet ./pkg/tbtcpg/...— no new issuesFindDeposits(MovingFunds path) still usesfilterStartBlock=0