eth_getLogs: `pending` block tag resolves to head+1 instead of coercing to `latest`

[osr21]

Summary

eth_getLogs on Arc Mainnet incorrectly handles the "pending" block tag. Most Reth RPC methods coerce pending → latest, but eth_getLogs resolves it as latest + 1 (the next, not-yet-produced block), returning an empty result set instead of the current head's logs.

Steps to reproduce

# This returns logs as expected
curl -s -X POST https://rpc.arc.io \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getLogs","params":[{"fromBlock":"latest","toBlock":"latest"}]}'

# This returns [] even when logs exist at the current head
curl -s -X POST https://rpc.arc.io \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getLogs","params":[{"fromBlock":"pending","toBlock":"pending"}]}'

The second call should either coerce to latest (matching Reth's behavior for other methods) or return an error. Returning an empty array silently misleads callers.

Impact

Frontend and indexer code that uses "pending" as a block tag for log queries (common in viem/ethers.js defaults) gets silent empty results, not an error. This is especially confusing during event monitoring where missing events looks like no activity rather than a misconfigured query.

Expected behaviour

Either:

• Coerce "pending" → "latest" for consistency with other RPC methods, or
• Return a structured error: {"code":-32602,"message":"pending block tag not supported for eth_getLogs"}

Environment

• Arc Mainnet (chain 5042)
• Observed via viem watchContractEvent and direct eth_getLogs calls

[osr21]

Hi — could a maintainer assign this issue to me (@osr21) so I can open a PR with the fix?

I have a patch ready in osr21:fix/eth-get-logs-pending-error that adds a -32602 error guard in NoPendingTransactionsRpcMiddleware::intercept_or_forward for eth_getLogs calls with a "pending" block tag, consistent with how other pending-block RPCs are already handled.