Function is_request_rejection 

fn is_request_rejection(res: &ResponsePacket) -> bool

Whether the response rejects the request itself: the result set it asks for is over the provider’s cap.

This recurs against a perfectly healthy provider. l1_events_max_block_range defaults to 10000, exactly infura’s result cap, and get_finalized_deposits retries a rejected chunk in a loop at l1_retry_delay, so scoring it would burn a generation every couple of seconds and cycle the whole provider list against a request every one of them rejects.

Only result-count rejections qualify. A block-range cap reads the same way but is a plan or node-config limit, not a property of the request: alchemy caps eth_getLogs at 10 blocks on the free tier and not at all on paid ones, so a backup may well serve the identical request and failing over is the right move.

Matched on the message because infura reuses -32005 for both a result-count rejection and a rate limit. Claiming it before [ErrorPayload::is_retry_err], which calls every -32005 a rate limit, is what makes deferring to alloy’s matcher safe here.