fix(input): smaller chainsync block batch

[wolf31o2]

Summary by cubic

Reduce chainsync block batch size and enlarge internal queues to prevent backpressure and “message queue limit exceeded” errors during catch-up sync. Improves Node-to-Node sync stability.

• Bug Fixes
  • Lowered blockBatchSize from 500 to 50 for GetBlockRange calls.
  • Increased eventChan buffer from 10 to 2048 to absorb event bursts.
  • Set RecvQueueSize to 100 (above PipelineLimit=50) to avoid queue limit errors.

^{Written for commit 6029d04. Summary will update on new commits.}

Summary by CodeRabbit

Release Notes

• Bug Fixes
  • Resolved message queue limit errors during rapid block synchronization operations
  • Enhanced event and block processing throughput for improved catch-up performance

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request modifies the chainsync component to adjust configuration parameters for improved message queuing during catch-up synchronization. The blockBatchSize constant is reduced from 500 to 50, the eventChan buffer is increased from 10 to 2048, and receive queue sizes are added to both Chainsync (100) and BlockFetch (512) configurations. These changes are accompanied by comments explaining their purpose in preventing backpressure and message queue limit errors during rapid block synchronization.

Possibly related PRs

• fix: set blockfetch recv queue size to under the limit #547: Modifies the same chainsync file and configures BlockFetch's receive queue size to 512, indicating coordinated tuning of block fetch parameters.

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix(input): smaller chainsync block batch' directly and specifically describes the main change: reducing the blockBatchSize constant in the chainsync module from 500 to 50.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/smaller-batches

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cubic-dev-ai]

No issues found across 1 file

[coderabbitai]

🧹 Nitpick comments (1)

input/chainsync/chainsync.go (1)

163-166: Derive channel capacity from sync constants to avoid future tuning drift.

Line 166 hard-codes 2048, but this is operationally coupled to blockBatchSize and pipeline behavior. Encoding that relation in constants will make future tuning safer.

♻️ Proposed refactor

 const (
 	// Size of cache for recent chainsync cursors
 	cursorCacheSize = 20

 	// blockBatchSize controls how many blocks are requested per GetBlockRange
 	// call during NtN catch-up sync. Must be small enough that the events
 	// generated (~20 per block) fit in the eventChan buffer to avoid
 	// backpressure that stalls the blockfetch recv queue and triggers
 	// "message queue limit exceeded" errors.
 	blockBatchSize = 50
+	estimatedEventsPerBlock = 20
+	eventChanBufferSize     = blockBatchSize * estimatedEventsPerBlock * 2
+	chainSyncPipelineLimit  = 50
+	chainSyncRecvQueueSize  = chainSyncPipelineLimit * 2

 	maxAutoReconnectDelay = 60 * time.Second
 	defaultKupoTimeout    = 30 * time.Second
 )
@@
-		c.eventChan = make(chan event.Event, 2048)
+		c.eventChan = make(chan event.Event, eventChanBufferSize)
@@
-				ochainsync.WithPipelineLimit(50),
+				ochainsync.WithPipelineLimit(chainSyncPipelineLimit),
 				// Recv queue must exceed pipeline limit to avoid "message queue
 				// limit exceeded" errors during rapid catch-up sync
-				ochainsync.WithRecvQueueSize(100),
+				ochainsync.WithRecvQueueSize(chainSyncRecvQueueSize),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@input/chainsync/chainsync.go` around lines 163 - 166, Replace the hard-coded
channel size when creating c.eventChan with a capacity computed from the sync
tuning constants (e.g., blockBatchSize and PipelineLimit) so the buffer scales
with those parameters; locate the c.eventChan = make(chan event.Event, 2048)
allocation and change it to compute capacity like (blockBatchSize *
PipelineLimit * <smallFactor>) or a similarly named constant derived from
blockBatchSize to preserve headroom, and ensure any new constant(s) are named
clearly (e.g., eventChannelMultiplier or eventBufferCapacity) and used in the
allocation so future tuning of blockBatchSize/PipelineLimit automatically
adjusts the channel size.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@input/chainsync/chainsync.go`:
- Around line 163-166: Replace the hard-coded channel size when creating
c.eventChan with a capacity computed from the sync tuning constants (e.g.,
blockBatchSize and PipelineLimit) so the buffer scales with those parameters;
locate the c.eventChan = make(chan event.Event, 2048) allocation and change it
to compute capacity like (blockBatchSize * PipelineLimit * <smallFactor>) or a
similarly named constant derived from blockBatchSize to preserve headroom, and
ensure any new constant(s) are named clearly (e.g., eventChannelMultiplier or
eventBufferCapacity) and used in the allocation so future tuning of
blockBatchSize/PipelineLimit automatically adjusts the channel size.

---

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e2394da and 6029d04.

📒 Files selected for processing (1)

• input/chainsync/chainsync.go