fix(cronos): bound concurrent ReplayBlock queries and honor the request context - #2179
fix(cronos): bound concurrent ReplayBlock queries and honor the request context#2179JayT106 wants to merge 5 commits into
ReplayBlock queries and honor the request context#2179Conversation
|
Warning Review limit reached
Next review available in: 25 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
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. Comment |
…st context Add an aggregate concurrency limit and context cancellation checks to the unauthenticated ReplayBlock gRPC query, so a handful of concurrent callers cannot saturate the node's EVM execution capacity even though each call already caps its own gas.
7026d9e to
264a5a6
Compare
Drop redundant/verbose comments across export_test.go, grpc_query.go, and the concurrency test file, keeping only non-obvious rationale.
|
@claude review |
Signed-off-by: JayT106 <JayT106@users.noreply.github.com>
Signed-off-by: JayT106 <JayT106@users.noreply.github.com>
1 participant
What
/cronos.Query/ReplayBlockis unauthenticated and runs real EVM execution — up toReplayBlockGasCap(60M, doubled to a 120M gas budget) andMaxReplayBlockMsgs(10000) messages per call. Those per-call caps were already in place, but nothing capped how many calls ran at once, so N concurrent requests meant N × 120M gas of parallel execution. The handler also never looked at the request context, so a client that disconnected or timed out mid-batch left the node grinding through the remaining messages for nothing.Solution
replayBlockConcurrency). Acquire is aselectagainst the caller's context, so a cancelled or expired request gives up instead of waiting.MaxConcurrentStreams, so an attacker can open arbitrarily many). An atomic counter now bounds running + queued at 16 and rejects beyond that withResourceExhausted. The check is a singleAddInt32compared against the bound with rollback on rejection — no check-then-act window, so concurrent callers can't overshoot.ctx.Err()is checked once per message inside the replay loop, converted viastatus.FromContextError, so a disconnect aborts the batch instead of running it out.Tradeoff:
cronos_replayBlockover JSON-RPC shares this pool, so heavy debugging use can now be rejected rather than queued. 4 is deliberately conservative for a heavy debug query.Test
grpc_query_replay_concurrency_test.gocovers the wait path (asserts the gRPC code, not wall-clock time — the request carries zero messages, soDeadlineExceededis reachable only through the semaphoreselect), the proceed path, and the queue-full rejection via test-only counter hooks inexport_test.go. Counter balance was traced across rejection, cancellation, panic, and every early return.