Improve Error Messaging for RPC Request Failures

[frankbonnet]

Is your feature request related to a problem?
When sending RPC requests to the node (e.g., https://mainnet.skalnodes.com/v1/green-giddy-denebola), we intermittently receive the following error response:

{"error":{"code":-32004,"message":"Invalid RPC parameters."},"id":1,"jsonrpc":"2.0"}

This error message is misleading because the exact same request with the same parameters often succeeds when retried. This inconsistency creates confusion, delays debugging efforts, and complicates the implementation of robust retry mechanisms.

Describe the solution you’d like
Improve the error messaging to reflect the underlying issue more accurately. If the error is caused by something other than invalid parameters (e.g., rate-limiting, timeout, or internal node issues), the message should convey the correct context. For example:

"Request rate limit exceeded"
"Node timeout or internal error"
"Temporary node unavailability"

Providing accurate error codes and descriptions would greatly help developers identify and address the root cause of issues.

Describe alternatives you’ve considered
We are implementing a retry mechanism to mitigate the impact of the misleading error message (already done).

Building an indexer to reduce dependency on batch RPC calls (currently in progress).

While these approaches help manage the symptom, they do not resolve the underlying issue of unclear error messaging, which could affect other developers and users relying on RPC nodes.

Additional context
This issue is particularly problematic for applications that need to sync large ranges of blocks (e.g., 2000-block batches). When synchronizing events for game clients, queries frequently fail with the misleading error despite using valid parameters.

We’ve included Fiddler snapshots with failed and successful requests using identical parameters, highlighting the inconsistency. The misleading error message caused significant debugging delays before we identified the workaround.

Providing more specific error messaging would improve developer experience and reduce wasted time on misdiagnosed issues.
2024-11-13-233820.zip