LukeMathWalker/tracing-actix-web

Make RequestId generation on each request optional

Tipnos opened this issue · 11 comments

Tipnos commented

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)?

What is the usecase?

Tipnos commented

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).