You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Alexandre Dutra <ad...@apache.org> on 2025/10/31 12:16:36 UTC
[DISCUSS] Should we echo the X-Request-Id header in the response?
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
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Prashant Singh <pr...@snowflake.com.INVALID>.
+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 <fl...@gmail.com> 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 <co...@gmail.com>
> 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 <di...@apache.org>
> > 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 <ad...@apache.org>
> > 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
> > > >
> > >
> >
>
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Yufei Gu <fl...@gmail.com>.
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 <co...@gmail.com>
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 <di...@apache.org>
> 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 <ad...@apache.org>
> 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
> > >
> >
>
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Michael Collado <co...@gmail.com>.
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 <di...@apache.org>
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 <ad...@apache.org> 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
> >
>
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Dmitri Bourlatchkov <di...@apache.org>.
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 <ad...@apache.org> 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
>
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Alexandre Dutra <ad...@apache.org>.
Hi all,
Just closing the loop: the PR to rename the header was merged yesterday [1].
The request ID is still being echoed as before: nothing changed in
that regard, which is what the community wants.
Thanks,
Alex
[1]: https://github.com/apache/polaris/pull/2988
On Tue, Nov 4, 2025 at 3:39 AM Adnan Hemani
<ad...@snowflake.com.invalid> wrote:
>
> +1 to echoing the Request ID in all cases. I've made the case for this
> previously on the predecessor thread:
> https://lists.apache.org/thread/0ocsqmvd3kzk3qwkf1tcflgztp5rqtqr.
>
> I'm okay with putting a feature flag around this in the future, if there
> are users who consider this to be noise. But I don't think we need this
> today.
>
> Best,
> Adnan Hemani
>
> On Sun, Nov 2, 2025 at 12:16 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Hi
> >
> > I'm in favor of still echoing the X-Request-Id header. The purpose is
> > to define a kind of correlation and idempotency, established by the
> > client. It's a "classic" pattern in messaging systems.
> > For instance, in many Apache Camel routes dealing with REST endpoints,
> > we usually define X-Request-Id header in POST, PUT, and PATCH to
> > ensure idempotent message processing in case of a retry.
> >
> > So, it's up to a client to deal with X-Request-Id in response (and do
> > the correlation if needed).
> >
> > To simplify the "engineering", we could only echo X-Request-Id if
> > provided in the request.
> >
> > Regards
> > JB
> >
> > On Fri, Oct 31, 2025 at 1:16 PM Alexandre Dutra <ad...@apache.org> 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
> >
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Adnan Hemani <ad...@snowflake.com.INVALID>.
+1 to echoing the Request ID in all cases. I've made the case for this
previously on the predecessor thread:
https://lists.apache.org/thread/0ocsqmvd3kzk3qwkf1tcflgztp5rqtqr.
I'm okay with putting a feature flag around this in the future, if there
are users who consider this to be noise. But I don't think we need this
today.
Best,
Adnan Hemani
On Sun, Nov 2, 2025 at 12:16 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi
>
> I'm in favor of still echoing the X-Request-Id header. The purpose is
> to define a kind of correlation and idempotency, established by the
> client. It's a "classic" pattern in messaging systems.
> For instance, in many Apache Camel routes dealing with REST endpoints,
> we usually define X-Request-Id header in POST, PUT, and PATCH to
> ensure idempotent message processing in case of a retry.
>
> So, it's up to a client to deal with X-Request-Id in response (and do
> the correlation if needed).
>
> To simplify the "engineering", we could only echo X-Request-Id if
> provided in the request.
>
> Regards
> JB
>
> On Fri, Oct 31, 2025 at 1:16 PM Alexandre Dutra <ad...@apache.org> 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
>
Re: [DISCUSS] Should we echo the X-Request-Id header in the response?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
I'm in favor of still echoing the X-Request-Id header. The purpose is
to define a kind of correlation and idempotency, established by the
client. It's a "classic" pattern in messaging systems.
For instance, in many Apache Camel routes dealing with REST endpoints,
we usually define X-Request-Id header in POST, PUT, and PATCH to
ensure idempotent message processing in case of a retry.
So, it's up to a client to deal with X-Request-Id in response (and do
the correlation if needed).
To simplify the "engineering", we could only echo X-Request-Id if
provided in the request.
Regards
JB
On Fri, Oct 31, 2025 at 1:16 PM Alexandre Dutra <ad...@apache.org> 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