feat: Add Request ID header to RPC requests for easier debugging

[ahhda]

Problem

Our JSON RPC requests currently don't send any information that would make it easier to track the particular request to debug. Adding the Request ID header to each JSON RPC request will help debug individual failing RPC calls.

Suggested solution

Add a unique request id header to all JSON RPC calls

This is what our request looks like currently:

 {"args":{},"headersIn":{"content-type":"application/json","accept":"*/*","user-agent":"cowprotocol-services/2.0.0","accept-encoding":"gzip","host":"mainnet.eth-node-proxy.svc.cluster.local","content-length":"200"},"headersOut":{},"httpVersion":"1.1","internal":false,"method":"POST","remoteAddress":"10.0.169.177","requestText":"{\"jsonrpc\":\"2.0\",\"method\":\"eth_getLogs\",\"params\":[{\"address\":\"0x9008d19f58aabd9ed0d60971565aa8510560ab41\",\"blockHash\":\"0x467a3a9beff034e6a525451b33c010cc532796bdc709560de6e11d4e7e587db6\"}],\"id\":82969}","status":0,"uri":"/"}

[rferrandop]

Hi! I'd like to address this issue, if that's alright.

I have a couple of questions:

1. Is the request ID you mentioned intended to be a UUID generated for each RPC request?
2. Also, should the header name adhere to a standardized nomenclature that integrates well with the current application? Are there any other header names used for this purpose? I ask to ensure consistency with other headers serving similar purposes in the application. For example, X-Request-Id.
3. If I am not wrong, would the change be implemented here?
   

   services/crates/ethrpc/src/http.rs

   Line 77 in 11e356c

   .header(header::CONTENT_TYPE, "application/json")

[fleupold]

Hi @rferrandop, thanks for taking a look here (and sorry for the delay in responding). The place you pointed out for the code change looks correct to me.

We already have a X-Request-ID for the top level request that the api or driver crate is processing (which gets logged in each span and is captured here). It would be ideal to also set this ID.

I'm not sure if @ahhda was thinks it is helpful to add RPC request id (there may be many downstream sub-requests for one top level API request being processed) as well or if we already have visibility into this. @ahhda could you advise?

[ahhda]

Currently, we don't have visibility around individual RPC requests.

So if the driver crate reports an RPC request failed, we don't know which request does it correspond to in our RPC logs.

I would say, generate a new UUID and add it as a header (RPC-Request-ID maybe?) to individual requests so that we can match all failed RPC requests that services reports in RPC logs.

Adding existing X-Request-ID to the RPC requests, would also be a good add-on so that it is easier to club RPC logs based on the top level request.

[fleupold]

I would say, generate a new UUID and add it as a header

RPC requests already have a unique ID per request (passed into the execute_request method @rferrandop linked above). Let's use this one then.

[rferrandop]

I hereby enter the secret pass phrase: 🐮