You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
do not poll more than the configured amount when filling gaps (#123)
### TL;DR
Added a limit to the number of blocks that can be polled when handling gaps in block sequences.
### What changed?
- Added a check to limit the number of missing blocks to poll based on the poller's `blocksPerPoll` configuration
- Reordered logging statements for better clarity
- Added debug logging to indicate when block polling is limited due to configuration
### How to test?
1. Configure a low `blocksPerPoll` value
2. Create a scenario with a large gap between expected and actual block numbers
3. Verify that the number of polled blocks is capped at the configured `blocksPerPoll` value
4. Check debug logs to confirm the limitation message appears
### Why make this change?
To prevent potential performance issues and resource exhaustion when handling large gaps in block sequences. This change ensures the system maintains stability by limiting the number of blocks that can be polled in a single operation.
log.Debug().Msgf("Detected %d missing blocks between blocks %s and %s", missingBlockCount, expectedStartBlockNumber.String(), actualFirstBlock.Number.String())
187
193
188
-
poller:=NewBoundlessPoller(c.rpc, c.storage)
189
194
log.Debug().Msgf("Polling %d blocks while handling gap: %v", len(missingBlockNumbers), missingBlockNumbers)
190
195
poller.Poll(missingBlockNumbers)
191
196
returnfmt.Errorf("first block number (%s) in commit batch does not match expected (%s)", actualFirstBlock.Number.String(), expectedStartBlockNumber.String())
0 commit comments