do not poll more than the configured amount when filling gaps

[iuwqyir]

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.

[iuwqyir]

• decode events #125
• Add transaction data decoding support #124
• do not poll more than the configured amount when filling gaps #123 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[iuwqyir]

Merge activity

• Dec 6, 2:56 PM EST: A user started a stack merge that includes this pull request via Graphite.
• Dec 6, 2:56 PM EST: A user merged this pull request with Graphite.