+1 from my side on sending an X-Request-Id in the response too. This is helpful in case the client didn't generate request-id and wanna co-relate the client side req to their server logs IMHO it's also fine to make it configurable too if folks have better request tracing or consider this as a noise, they can turn it off.
Best, Prashant Singh On Fri, Oct 31, 2025 at 4:03 PM Yufei Gu <[email protected]> wrote: > 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 > > > > > > > > > >
