Option 1 seems more consistent so that clients can correlate logs or events for better debuggabilities. I'd suggest to return it even it was generated by Polaris, not clients/Envoy/LBs.
As I mentioned in this thread https://lists.apache.org/thread/p9357rcy3d1j94w4yogtdwcf2kxzg3jr, I'd consider not mixing Otel context with request ID, and make Otel separated and optional. Yufei On Fri, Oct 31, 2025 at 1:42 PM Michael Collado <[email protected]> wrote: > My preference is to continue returning the x-request-id response header. > Istio/Envoy and other service proxies include the x-request-id in logs, > meaning that if users have a request id to report, we can more easily > diagnose issues by tracing through the LB and service logs. Some of our > users are including traceparent headers, but IME most clients don't have > OTEL set up in their data applications. > > Mike > > On Fri, Oct 31, 2025 at 9:08 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > AFAIK the "X-Request-Id" header is not well-defined. I could not find any > > docs about it in RFCs or W3C publications, but Wikipedia [1] lists it as > > "non-standard" both in requests and responses and "superseded" by > > "traceparent" in requests. > > > > My preference is option (2): no "X-Request-Id" header in responses. > > > > I'm also ok with options (1), but I believe it would be valuable to cover > > that functionality with a feature flag, which is "off" by default. This > is > > to avoid making the impression that the "X-Request-Id" header is promoted > > by Polaris as the main method for request correlation. From the overall > > project's perspective, I believe we should align with and support OTel > > standards for observability / request correlation. > > > > [1] https://en.wikipedia.org/wiki/List_of_HTTP_header_fields > > > > Cheers, > > Dmitri. > > > > On Fri, Oct 31, 2025 at 8:17 AM Alexandre Dutra <[email protected]> > wrote: > > > > > Hi all, > > > > > > This thread follows up on [1] to discuss whether we should echo the > > > client-generated X-Request-Id header in the response. > > > > > > Before Quarkus, the situation was unclear: Polaris on Dropwizard [2] > > > did not seem to echo the header, but Dropwizard itself has a > > > RequestIdFilter that does [3]. > > > > > > We have two options: > > > > > > 1) Echo the X-Request-Id header. > > > - Pros: Allows clients to correlate requests and responses. > > > - Cons: risk of over-engineering since we don't have users asking > for > > > this. > > > > > > 2) Do not echo the X-Request-Id header. > > > - Pros: No action required on the Polaris side. > > > - Cons: None apparent. > > > > > > I don't have a strong opinion, but I slightly favor option 1 to > > > accommodate those who strongly value this feature. > > > > > > Thoughts? > > > > > > Thanks, > > > Alex > > > > > > [1] https://lists.apache.org/thread/bb1qyxjt827t3tomv2xp0s1kovxjsp94 > > > [2] > > > > > > https://github.com/apache/polaris/blob/4b18ec065ff16f74b11bc85fdc6ea9036eca7274/dropwizard/service/src/main/java/org/apache/polaris/service/dropwizard/PolarisApplication.java#L516 > > > [3] > > > > > > https://github.com/dropwizard/dropwizard/blob/3833f0e1d9fb8cae256fe09379733b8d651f8b87/dropwizard-jersey/src/main/java/io/dropwizard/jersey/filter/RequestIdFilter.java#L42-L49 > > > > > >
