tracing-actix-web
tracing-actix-web copied to clipboard
LukeMathWalker
Make RequestId generation on each request optional
Hi,
first thank you for publishing this crate.
As mentioned in the title would you agree to make the RequestId generation optional (with feature flag or configuration)?
The use case is to avoid the overhead of generating uuid v4 on each request.
In our infra the gateway is already generating one.
Here is our use case:
In our server, we are already receiving a request ID from our client using an X-Request-Id header. Folks searching for spans in the Jaeger UI or reviewing spans dumped in logs will get confused if request ID is a value generated by the tracing actix web rather than what was passed in on the header. I have to tell people to ignore the request_id attribute.
I see a couple ways to satisfy my use case:
- Extract X-Request-Id header and use that when present OR
- Allow request_id to by empty on the span so I can later "span.record" myself OR
- allow me to construct a RequestId with a UUID (or string!) of my choice and then I can clobber the one generated by tracing actix web before it creates the root span.
Probably many other ways to do it too.
There should be a clear differentiation between a client-generated request id and a server-generated request id. The lack of support for "use this header as request id" is entirely intentional here.
Disabling the generation is something I'm open to.
Disabling sounds like it will work for our use case. FWIW, the role of server-generated request ID is the OpenTelemetry trace ID or root span ID.
FWIW, the role of server-generated request ID is the OpenTelemetry trace ID or root span ID.
Is that meant to be a question or a statement? 👀 The trace ID and the server-generated request ID are two different things. The trace ID will be the same across all services that touch the request, while the request ID will be unique within each service (especially if the same service is invoked twice within the same trace).
I am also in a situation where "Extract X-Request-Id header and use that when present OR" would be the preferred option, any reason why you're against this @LukeMathWalker ?
I am also in a situation where "Extract X-Request-Id header and use that when present OR" would be the preferred option, any reason why you're against this @LukeMathWalker ?
It's an anti-pattern. Request id should always have a consistent meaning—it should either be client-generated or server-generated, not a bit of both depending on the situation.
X-Request-ID is a log corelation tool, it makes sense for it to be client provided. I can see optional server generation be an issue for something else, like an idempotency key, but that's not what request id is used for.
Client-generated IDs are fine. Using the same type for both client-generated and server-generated is a bad idea.
This crate provides a server-generated id. You can add your client generated one on top, if you want to.
Just FYI: this crate does in fact use the same type for both client and server generated ids from the traceparent header, which populates trace_id.