L1 PLEX-2601 LP Fetch Blocks in Batches

[dhaidashenko]

Summary

PLEX-2601 — Batch block fetching inside the log poller loader so slot discovery via getSignaturesForAddress runs once per backfill range, instead of restarting for every slot-range batch.

Problem

Previously, large backfills were split in the log poller into multiple independent slot ranges. Each range called BackfillForAddresses, which re-ran getSlotsToFetch from the newest signatures. Pagination (beforeSig) did not carry across adjacent batches, so every batch effectively rediscovered recent history and walked backward again. That added redundant RPC load, slowed deep catch-up on hot addresses, and could worsen throttling or recovery time in worst cases.

Solution

• Revert batching at the poller layer (processBlocksRangeInBatches / per-batch BackfillForAddresses).
• Move batching to EncodedLogCollector: after a single getSlotsToFetch pass for [fromSlot, toSlot], scheduleBlocksFetching processes the resulting slot list in chunks of LogPollerSlotsBatchSize (limits concurrent getBlock work / memory), while signature discovery pagination stays coherent for the whole range.
• Lower the default LogPollerSlotsBatchSize to further limit memory usage, as getSlotsToFetch no longer executed multiple times.

[github-actions]

⚠️ API Diff Results - github.com/smartcontractkit/chainlink-solana

⚠️ Breaking Changes (1)

pkg/solana/logpoller (1)

• NewEncodedLogCollector — Type changed:

func(
  RPCClient, 
  github.com/smartcontractkit/chainlink-common/pkg/logger.Logger, 
  string, 
  *solLpMetrics, 
  *CPIEventExtractor, 
  + int64
)
*EncodedLogCollector

---

📄 View full apidiff report

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
83.3% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[jadepark-dev]

lgtm