Hi Adnan, Let's please avoid revisiting previously agreed-upon topics. We had general agreement that generating request IDs is unnecessary. Mike's opinion [1] supports this, and even you agreed [2]. Therefore, I'm surprised by your sudden change of mind.
With that, I believe this discussion is now going in circles. Let's split it into 2 new threads to address the remaining open issues *separately*: 1) Whether the request ID sent by the client should be echoed in the response. 2) How to persist request IDs and OTel traces. Thanks, Alex [1] https://lists.apache.org/thread/zkmj8slsl3xyd0kzjdvnjqhh4rz0grlw [2] https://lists.apache.org/thread/gvk05h7tnv4b513gr2bmyobqzmm2sos2 On Fri, Oct 31, 2025 at 1:35 AM Adnan Hemani <[email protected]> wrote: > > Hi Dmitri, > > Thanks for this - I am understanding what you are saying directly, but I’m > not sure I am understanding the implications of those statements. Can you > please help clarify the following? > > Re: separation of “observability/debuggability” vs “functional” use cases: > I agree that the request ID is not a hard requirement for the correctness of > the server or client, in general. Maybe there is a use case that exists, but > I am not aware of that either. So what I’m gathering from this is that there > is not really a “functional” use case here. If you’re referring to the > ability of a upstream system (such as any load balancer) to mark a request ID > and have Polaris respect that as “functional” - I’m not sure it’s really all > that different than an “observability” use case either. I’m not convinced > either way - but if you can expand further on this, it may help me see your > point. > > Re: propagating request IDs upwards > I don’t find this awkward, TBH. This is how most web systems I’ve ever worked > with work. The ability to request a specific Request ID tend to be optional, > but receiving back a Request ID (regardless of whether it was generated for > you, or you had requested it and it was respected) through a header is quite > standard. I don’t see how Polaris is any different - happy to hear why this > would be the case. > > But even in the case that a client is trying to relate requests for a certain > “unit of work” on their end, they have the ability to do so by using the > `X-Request-Id` request header and Polaris should respect that value and > resend the same request ID back as a response header. This actually makes > things even clearer for the client to confirm that their Request ID was > indeed respected. > > Thoughts? > > Best, > Adnan Hemani > > > > > On Oct 30, 2025, at 3:53 PM, Dmitri Bourlatchkov <[email protected]> wrote: > > > > Hi Adnan, > > > > Re: request ID headers in responses (point 4 in your email): > > > > I believe we need to distinguish observability / debuggability use cases > > from "functional" use of request IDs. By functional I mean clients that > > actually rely on the request ID value in order to perform their job > > properly. > > > > I do believe we're discussing the first use case in this thread. Meaning > > that request IDs are auxiliary pieces of information that are not critical > > for correctness of operation in the larger context. However, please correct > > me if I'm wrong here. > > > > That said, for observability / debugging use cases one normally establishes > > the request ID as early as possible and then propagates it to lower-level > > systems. Propagating request IDs upward is awkward because a client making > > multiple calls to Polaris as part of the same logical request on its side > > will end up with different polaris request IDs, so linking them to the > > client-side "unit of work" will require extra machinery. > > > > WDYT? > > > > Thanks, > > Dmitri. > > > > On Thu, Oct 30, 2025 at 5:44 PM Adnan Hemani > > <[email protected]> wrote: > > > >> Hi folks, > >> > >> Unfortunately, I don’t agree on most of the discussion past Alex’s > >> re-summarization. I do, however, agree on the requirements stated by Alex > >> in that email. > >> > >> Here’s what I believe we should be doing in summary: > >> 1. Keep the existing `request_id` column. > >> * To be fair, I don’t fully understand the reason why we are > >> trying to change a ubiquitous concept such as `request_id` to something > >> named as `correlation_id`. Are we trying to state explicitly that the > >> correlation ID and request ID should/are not be the same? If someone can > >> please explain this part, that would be helpful. > >> 2. In the `request_id` field, use the `X-Request-Id` header value if it > >> exists - as that is explicitly what the client is asking for and will mark > >> as the request ID in their logs. > >> 2a. Otherwise, use the OTel Trace ID as the request ID. This > >> should always exist, as it is provided by Quarkus on a per-request basis. > >> 2b. If, in the future, we are not provided an OTel Trace ID (for > >> whatever reason), one should be generated. > >> 4. Keep the `request_id` as part of the response headers. > >> * This allows clients to note down what the request ID that was > >> used and/or generated. Without it, how will clients who don’t provide a > >> `X-Request-Id` header be able to communicate which request they are > >> referring to if they need to debug something? > >> 5. I’m unsure on indexing over request_id or keeping the request_id_type. > >> I don’t see these as a hard use case today, but we can always add it as an > >> improvement in the future. > >> > >> To put this all another way (perhaps more philosophically, but the way I > >> am thinking about things in general): > >> * There should be exactly 1 request ID that is used when a client makes a > >> request to Polaris. That request ID can be dictated by the client (which I > >> still find a bit odd when looking at web server architecture in general, > >> but I understand the use case we have for it) or generated by the server. > >> * That request ID should then be used in any persisting anything that > >> involve request identification (in this particular case, for Events, but > >> not limited to if there’s something else in the future.) > >> * That request ID should be made aware of to the client, so it knows how > >> to identify the request in the case of future debugging. > >> > >> Please let me know your thoughts. > >> > >> Best, > >> Adnan Hemani > >> > >> > >>> On Oct 30, 2025, at 10:26 AM, Dmitri Bourlatchkov <[email protected]> > >> wrote: > >>> > >>> Hi Alex, > >>> > >>> SGTM (both not using request ID _response_ headers and deferring type > >> info > >>> in correlation ID values). > >>> > >>> Cheers, > >>> Dmitri. > >>> > >>> On Thu, Oct 30, 2025 at 1:04 PM Alexandre Dutra <[email protected]> > >> wrote: > >>> > >>>> Hi Dmitri, > >>>> > >>>>> I believe we still need to clarify / confirm whether returning any > >>>> request / correlation ID in _response_ headers is required. > >>>> > >>>> Indeed, that specific item was still pending. FYI I'm going to > >>>> *remove* the echoing of the request ID in the response headers, unless > >>>> someone objects. > >>>> > >>>>> it could be useful to embed some type data into the value to help with > >>>> interpretation > >>>> > >>>> I'm not sure we need this at this moment. I'd suggest that we leave > >>>> this for further improvements in order to not over-specify the > >>>> requirements. Given that the events feature is beta, this shouldn't be > >>>> a problem. > >>>> > >>>> Thanks, > >>>> Alex > >>>> > >>>> > >>>> On Thu, Oct 30, 2025 at 5:22 PM Dmitri Bourlatchkov <[email protected]> > >>>> wrote: > >>>>> > >>>>> Thanks for the nice summary, Alex! > >>>>> > >>>>> To All: > >>>>> > >>>>> I'm not sure an INDEX on correlation_id is that useful... Polaris > >> itself > >>>>> does not use that index, right? Do we expect end users to query events > >>>>> directly from the database? This will work only with RDBMS, but > >> probably > >>>>> not with the proposed NoSQL persistence. > >>>>> > >>>>> I believe we still need to clarify / confirm whether returning any > >>>> request > >>>>> / correlation ID in _response_ headers is required. > >>>>> > >>>>> From my POV, I do not see a use case for it, but I wonder what other > >>>> people > >>>>> think / need. > >>>>> > >>>>> As for persisting correlation ID type, I agree that we do not need a > >>>>> separate column for that. Still, it could be useful to embed some type > >>>> data > >>>>> into the value to help with interpretation, specifically for telemetry > >>>> use > >>>>> cases (both x-request-id and OTel). For example, we could > >>>>> persist "traceparent:00-12345-...". Then, the reader would be able to > >>>>> identify this as information following the W3C spec [1], parse it and > >>>> link > >>>>> to other traces (if desired). That processing is optional and at the > >>>>> discretion of the event data reader, but making the value no-so-opaque > >>>>> upfront can enable a lot of interesting options for users without much > >>>>> extra overhead in Polaris. WDYT? > >>>>> > >>>>> [1] > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.w3.org/TR/2021/REC-trace-context-1-20211123/%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw1K633xlm1Dj0NjcNcpd41A&source=gmail-imap&ust=1762469626000000&usg=AOvVaw3FJYjDvXW1ifT-dq78bLOy > >>>>> > >>>>> Thanks, > >>>>> Dmitri. > >>>>> > >>>>> On Thu, Oct 30, 2025 at 6:04 AM Alexandre Dutra <[email protected]> > >>>> wrote: > >>>>> > >>>>>> Hi all, > >>>>>> > >>>>>>> we would only persist one or the other, not both. > >>>>>> > >>>>>> My apologies, I confess that this wasn't my understanding of the > >>>> desired > >>>>>> design. > >>>>>> > >>>>>> Let's try to gather the requirements again: > >>>>>> > >>>>>> 1. Only one correlation ID is enough > >>>>>> 2. The correlation ID is an opaque string > >>>>>> 3. The main use case is to find events with matching correlation IDs > >>>>>> 4. The only query pattern is by exact match > >>>>>> > >>>>>> Regarding *where* to store the correlation ID, and expanding on what > >>>>>> Dmitri said: the requirement to find matching records by correlation > >>>>>> ID clearly suggests a separate column, and with an INDEX on it. > >>>>>> Storing it in additional_properties will be inefficient. > >>>>>> > >>>>>> If we all agree on the above, here is what I propose: > >>>>>> > >>>>>> 1. Rename the existing column request_id to correlation_id; > >>>>>> 2. Populate from OTel context if available; the exact syntax is > >>>>>> implementation-specific; > >>>>>> 3. Otherwise, populate from X-Request-Id header if available; > >>>>>> 4. Otherwise, don't populate. > >>>>>> 5. Create an INDEX on correlation_id. > >>>>>> > >>>>>> You'll notice that we don't store the ID type, but that doesn't seem > >>>>>> necessary. > >>>>>> > >>>>>> What do you all think? > >>>>>> > >>>>>> Thanks, > >>>>>> Alex > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Wed, Oct 29, 2025 at 8:58 PM Dmitri Bourlatchkov <[email protected] > >>> > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Yufei, > >>>>>>> > >>>>>>> [...] tying a BeforeUpdateTable event to the corresponding > >>>>>> AfterUpdateTable > >>>>>>> event. > >>>>>>> > >>>>>>> > >>>>>>> It looks like this calls for a strong and always present ID in > >>>>>> events.This > >>>>>>> ID is obviously distincts from OTel context information and should be > >>>>>>> persisted separately, IMHO. > >>>>>>> > >>>>>>> I believe there's still an open question whether the request ID in > >>>> the > >>>>>>> events should be populated from the x-request-id in REST API headers. > >>>>>>> > >>>>>>> Yufei: Is that required in your use cases? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Dmitri. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Oct 29, 2025 at 1:05 PM Yufei Gu <[email protected]> > >>>> wrote: > >>>>>>> > >>>>>>>> I think the first question is whether any downstream use cases > >>>> need to > >>>>>>>> interpret the semantics of a request ID or OTel context. As I > >>>>>> mentioned, > >>>>>>>> the original purpose of a request ID was event correlation, e.g., > >>>>>> tying a > >>>>>>>> BeforeUpdateTable event to the corresponding AfterUpdateTable > >>>> event. If > >>>>>>>> that’s the only requirement, an opaque correlation ID is good > >>>> enough. > >>>>>> We > >>>>>>>> could change the field name(request-id) if needed. > >>>>>>>> > >>>>>>>> If we do have use cases that depend on the meaning of the request > >>>> ID or > >>>>>>>> OTel context, we can store them in additional_properties ( > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://github.com/polaris-catalog/polaris/blob/main/persistence/relational-jdbc/src/main/resources/postgres/schema-v3.sql%2523L134-L134%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw3kHvvqJhJTJi61gR6c6CFy&source=gmail-imap&ust=1762469626000000&usg=AOvVaw0kUL91EJEo0g8DuALtlFaF > >>>>>>>> ). > >>>>>>>> This is more flexible because it allows us to: > >>>>>>>> 1. Record a key that indicates the format (e.g., x-request-id vs. > >>>>>>>> otel-context). > >>>>>>>> 2. Preserve both when Polaris receives both headers. > >>>>>>>> 3. Add future tracing fields without a schema change. > >>>>>>>> > >>>>>>>> Yufei > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Oct 29, 2025 at 9:20 AM Dmitri Bourlatchkov < > >>>> [email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi All, > >>>>>>>>> > >>>>>>>>> From my POV the use cases for x-request-id and OTel are slightly > >>>>>>>> different. > >>>>>>>>> OTel is an observability use case where cross-linking of various > >>>>>> pieces > >>>>>>>> of > >>>>>>>>> data is desired but not required in all cases (data loss is > >>>>>> acceptable). > >>>>>>>>> The x-request-id use case appears to have some very specific > >>>> custom > >>>>>>>>> applications without any obvious relationship to OTel. > >>>>>>>>> > >>>>>>>>> Given the current state of this discussion, I think it makes > >>>> sense to > >>>>>>>>> handle and persist them separately. > >>>>>>>>> > >>>>>>>>> However, if we intend x-request-id to act as an observability aid > >>>>>>>>> alternative to OTel, then it might be preferable to have a config > >>>>>> flag > >>>>>>>>> indicating which one of them should be added to persistent event > >>>>>> data. In > >>>>>>>>> that case we should reuse the same column for them (and possibly > >>>> add > >>>>>> a > >>>>>>>>> "type" prefix, e.g. "x-request-id:ABCDEF" or > >>>>>> "traceparent:00-12345...") > >>>>>>>>> > >>>>>>>>> WDYT? > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Dmitri. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Wed, Oct 29, 2025 at 9:38 AM Alexandre Dutra < > >>>> [email protected]> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> Hi Yufei, > >>>>>>>>>> > >>>>>>>>>>> I’d suggest persisting a single opaque correlation ID instead > >>>>>>>>>> > >>>>>>>>>> The problem I see with this is that readers cannot know the > >>>> syntax > >>>>>> of > >>>>>>>>>> the opaque id, and will have to "probe" using some heuristics, > >>>>>> e.g. if > >>>>>>>>>> the id matches the OTel trace context syntax, asume it's OTel, > >>>>>>>>>> otherwise... assume it's something else. > >>>>>>>>>> > >>>>>>>>>> That's not unfeasible, but I wonder if it isn't better to store > >>>>>> the 2 > >>>>>>>>>> ids separately. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> Alex > >>>>>>>>>> > >>>>>>>>>> On Tue, Oct 28, 2025 at 7:14 PM Yufei Gu <[email protected] > >>>>> > >>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Thanks Alex for raising this discussion. Thanks everyone for > >>>>>> chiming > >>>>>>>>> in. > >>>>>>>>>>> The plan looks good to me overall. > >>>>>>>>>>> > >>>>>>>>>>>> Update PolarisEvent, expose request ID if available, expose > >>>>>> OTel > >>>>>>>>>> context > >>>>>>>>>>> if available. > >>>>>>>>>>> > >>>>>>>>>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://github.com/apache/polaris/pull/2914%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw33p8lOR4oYEJqcbo4Sm74f&source=gmail-imap&ust=1762469626000000&usg=AOvVaw1aWh6q_9-TX1Ao82MTOmiZ > >> persists both > >>>>>> request id > >>>>>>>>> and > >>>>>>>>>>> otel context. > >>>>>>>>>>> > >>>>>>>>>>> Do we actually need to persist both? > >>>>>>>>>>> From the original discussion, the intent of a request ID was > >>>> to > >>>>>>>>> correlate > >>>>>>>>>>> multiple events generated by the same request, for example, > >>>>>> linking a > >>>>>>>>>>> BeforeUpdateTable and an AfterUpdateTable event. In that > >>>> sense, > >>>>>> what > >>>>>>>> we > >>>>>>>>>>> really need is a single opaque identifier that ties related > >>>>>> events > >>>>>>>>>>> together, regardless of whether it comes from a request ID > >>>> or an > >>>>>> OTel > >>>>>>>>>>> context. > >>>>>>>>>>> > >>>>>>>>>>> If we persist both fields (requestId and otelContext), it can > >>>>>> lead to > >>>>>>>>>>> consumer confusion, since downstream systems would need to > >>>> decide > >>>>>>>> which > >>>>>>>>>> one > >>>>>>>>>>> to rely on, potentially causing inconsistent event > >>>> correlation. > >>>>>>>> Unless > >>>>>>>>>>> there are concrete use cases where event consumers need > >>>> both, I’d > >>>>>>>>> suggest > >>>>>>>>>>> persisting a single opaque correlation ID instead. This > >>>> keeps the > >>>>>>>>> schema > >>>>>>>>>>> simpler and ensures consistent event linking. > >>>>>>>>>>> > >>>>>>>>>>> Yufei > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Oct 28, 2025 at 10:08 AM Alexandre Dutra < > >>>>>> [email protected]> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi all, > >>>>>>>>>>>> > >>>>>>>>>>>> Here is the PR: > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://github.com/apache/polaris/pull/2914%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw33p8lOR4oYEJqcbo4Sm74f&source=gmail-imap&ust=1762469626000000&usg=AOvVaw1aWh6q_9-TX1Ao82MTOmiZ > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> Alex > >>>>>>>>>>>> > >>>>>>>>>>>> On Sun, Oct 26, 2025 at 5:49 PM Jean-Baptiste Onofré < > >>>>>>>>> [email protected]> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yeah it looks good to me and I agree we have a consensus. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks ! > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> JB > >>>>>>>>>>>>> > >>>>>>>>>>>>> Le dim. 26 oct. 2025 à 14:29, Alexandre Dutra < > >>>>>> [email protected] > >>>>>>>>> > >>>>>>>>> a > >>>>>>>>>>>> écrit : > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks for the good discussion so far. I think we have > >>>> a > >>>>>> broad > >>>>>>>>>>>> consensus. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Unless anybody disagrees I am going to move forward > >>>> with > >>>>>> the > >>>>>>>> the > >>>>>>>>>>>>>> following revised plan, incorporating the latest > >>>> feedback: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 1. Restore the original functionality for request IDs, > >>>>>> change > >>>>>>>> the > >>>>>>>>>>>>>> default header name back to x-request-id > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 2. Remove RequestIdGenerator and related functionality. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 3. Update PolarisEvent, expose request ID if available, > >>>>>> expose > >>>>>>>>> OTel > >>>>>>>>>>>>>> context if available. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 4. Update events table SQL schema: insert request ID if > >>>>>>>>> available, > >>>>>>>>>>>>>> insert OTel context if available. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> Alex > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Sat, Oct 25, 2025 at 11:12 AM Jean-Baptiste Onofré < > >>>>>>>>>> [email protected] > >>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I think it's better to use w3c_trace_context (better > >>>>>> than two > >>>>>>>>>>>> fields). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regarding x-request-id, I think it's for a different > >>>>>> purpose, > >>>>>>>>>>>>>>> specifically for persistence. Personally, I think we > >>>> can > >>>>>>>>> achieve > >>>>>>>>>> the > >>>>>>>>>>>>>>> same with span and events. > >>>>>>>>>>>>>>> If we want to "distinguish" the two layers, it makes > >>>>>> sense to > >>>>>>>>>> have > >>>>>>>>>>>>>>> x-request-id (not sure it's super helpful). Else, I > >>>>>> think we > >>>>>>>>> can > >>>>>>>>>>>>>>> achieve the same with span/event. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Just my $0.01 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regards > >>>>>>>>>>>>>>> JB > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Sat, Oct 25, 2025 at 10:42 AM Adnan Hemani > >>>>>>>>>>>>>>> <[email protected]> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> +1 to all of Alex’s AIs with Dmitri’s suggested > >>>>>> changes as > >>>>>>>>>> well. > >>>>>>>>>>>> Great > >>>>>>>>>>>>>> find, Dmitri! > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I’m still debating with myself on whether we need > >>>> to > >>>>>> store > >>>>>>>>> the > >>>>>>>>>>>>>> `x-request-id` field as part of the Events persistence. > >>>>>> Can we > >>>>>>>>>> think > >>>>>>>>>>>> of a > >>>>>>>>>>>>>> good use case where this is more helpful to the user > >>>> than > >>>>>> the > >>>>>>>>> OTel > >>>>>>>>>>>>>> Trace/Span IDs? I am making the assumption here that > >>>> those > >>>>>> are > >>>>>>>>>> still > >>>>>>>>>>>> being > >>>>>>>>>>>>>> returned back to the client. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>> Adnan Hemani > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Oct 24, 2025, at 9:12 AM, Alexandre Dutra < > >>>>>>>>>> [email protected]> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi Dmitri, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yes, I think your suggestion to use just one > >>>> field > >>>>>>>>>>>> w3c_trace_context > >>>>>>>>>>>>>>>>> makes more sense than two fields (span_id and > >>>>>> trace_id). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> With that, I also think that we are slowly > >>>> drifting > >>>>>> into > >>>>>>>>>>>>>>>>> implementation considerations; let's get > >>>> consensus > >>>>>> on the > >>>>>>>>>> general > >>>>>>>>>>>>>>>>> design first, and we can certainly fine-tune the > >>>>>> actual > >>>>>>>>> Java > >>>>>>>>>>>> methods > >>>>>>>>>>>>>>>>> and SQL table columns in the future PR. WDYT? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> Alex > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Fri, Oct 24, 2025 at 5:14 PM Dmitri > >>>> Bourlatchkov < > >>>>>>>>>>>>>> [email protected]> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Hi All, > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Many thanks for the background info, Adnan! > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> +1 to action items proposed by Alex! > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Re: (3) Can we abstract request/trace info into > >>>> a > >>>>>>>> separate > >>>>>>>>>>>> object > >>>>>>>>>>>>>> without > >>>>>>>>>>>>>>>>>> exposing those accessors on the Event class > >>>>>> directly? > >>>>>>>> OTel > >>>>>>>>>>>> defines > >>>>>>>>>>>>>>>>>> trace/span concepts, but in request ID is a bit > >>>>>> foreign > >>>>>>>> to > >>>>>>>>>> OTel. > >>>>>>>>>>>>>> Having > >>>>>>>>>>>>>>>>>> tracing / request ID isolated in java could help > >>>>>> with > >>>>>>>>>>>> maintaining > >>>>>>>>>>>>>> it and > >>>>>>>>>>>>>>>>>> potentially supporting other (custom) tracing > >>>>>> methods. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Re: (4) I'd like to propose storing OTel > >>>> correlation > >>>>>>>> data > >>>>>>>>>> in the > >>>>>>>>>>>>>> form of a > >>>>>>>>>>>>>>>>>> standard context propagation string, e.g. W3C > >>>>>>>>> trace-context > >>>>>>>>>> [1] > >>>>>>>>>>>>>> (same value > >>>>>>>>>>>>>>>>>> as its HTTP header), so the column could be > >>>> called > >>>>>>>>>>>>>> w3c_trace_context or > >>>>>>>>>>>>>>>>>> simply trace_context. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Open question: do we need to write a separate, > >>>>>>>> individual > >>>>>>>>>> trace > >>>>>>>>>>>> ID > >>>>>>>>>>>>>> field in > >>>>>>>>>>>>>>>>>> SQL? I suppose it is not very useful since > >>>>>> correlating > >>>>>>>> it > >>>>>>>>> to > >>>>>>>>>>>> other > >>>>>>>>>>>>>> trace > >>>>>>>>>>>>>>>>>> data already requires understanding OTel context > >>>>>>>>> propagation > >>>>>>>>>>>> and a > >>>>>>>>>>>>>> query > >>>>>>>>>>>>>>>>>> against trace_context can still be made using > >>>>>>>>>> string-matching > >>>>>>>>>>>>>> clauses. We > >>>>>>>>>>>>>>>>>> could probably (additionally) store it in the > >>>>>> request_id > >>>>>>>>>> column > >>>>>>>>>>>> if > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> Polaris-specific request ID header is not set. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> As for span ID, I do not really see a use case > >>>> for > >>>>>>>>>> persisting it > >>>>>>>>>>>>>>>>>> individually. It is very specific to OTel trace > >>>> data > >>>>>>>>>>>> construction. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Actually, using the W3C trace context [1] > >>>> encoding > >>>>>>>>> probably > >>>>>>>>>>>> makes > >>>>>>>>>>>>>> sense in > >>>>>>>>>>>>>>>>>> the java event representation too. Interested > >>>>>> callers > >>>>>>>> can > >>>>>>>>>> easily > >>>>>>>>>>>>>> decode > >>>>>>>>>>>>>>>>>> this information since the format is > >>>> well-defined. > >>>>>> As a > >>>>>>>>> side > >>>>>>>>>>>>>> benefit, this > >>>>>>>>>>>>>>>>>> opens opportunities for downstream event > >>>> consumers > >>>>>> to > >>>>>>>>>> connect > >>>>>>>>>>>>>> (propagate > >>>>>>>>>>>>>>>>>> context) to traces that produced events based > >>>> on the > >>>>>>>> event > >>>>>>>>>> data > >>>>>>>>>>>>>> itself, > >>>>>>>>>>>>>>>>>> without relying on the intermediate frameworks. > >>>>>> This may > >>>>>>>>> be > >>>>>>>>>>>>>> desirable since > >>>>>>>>>>>>>>>>>> the current Polaris event persistence impl. > >>>> writes > >>>>>>>> events > >>>>>>>>> in > >>>>>>>>>>>>>> batches, so > >>>>>>>>>>>>>>>>>> the association to individual requests that > >>>> produced > >>>>>>>> those > >>>>>>>>>>>> events > >>>>>>>>>>>>>> is lost. > >>>>>>>>>>>>>>>>>> Whether to perform this kind of context > >>>> propagation > >>>>>> will > >>>>>>>>> be > >>>>>>>>>> at > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> discretion of the event consumer, of course > >>>>>> (outside of > >>>>>>>>>> Polaris > >>>>>>>>>>>>>> code). > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.w3.org/TR/trace-context/%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw2fn0lRsTx-f9r4PCz8wmJK%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw0JHBUVrCE7tookVBiFjNdP&source=gmail-imap&ust=1762469626000000&usg=AOvVaw2tTZYzZmafSmGBVhT4wv7Z > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> WDYT? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>> Dmitri. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Fri, Oct 24, 2025 at 7:18 AM Alexandre Dutra > >>>> < > >>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thank you for chiming in; the context around > >>>>>> request > >>>>>>>> IDs > >>>>>>>>>> is now > >>>>>>>>>>>>>> clear. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Trying to summarize this thread into actionable > >>>>>> items, > >>>>>>>>>> here's > >>>>>>>>>>>> what > >>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>> propose: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> 1. Restore the original functionality for > >>>> request > >>>>>> IDs. > >>>>>>>>>>>>>>>>>>> - Change the default header name back to > >>>>>>>> x-request-id > >>>>>>>>>>>> (despite > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> x- prefix being deprecated), but keep it > >>>>>> configurable > >>>>>>>> as > >>>>>>>>>> today. > >>>>>>>>>>>>>>>>>>> 2. Remove RequestIdGenerator and related > >>>>>> functionality. > >>>>>>>>>>>>>>>>>>> - Do not generate a request ID if the REST > >>>>>> client > >>>>>>>>>> doesn't > >>>>>>>>>>>>>> provide one. > >>>>>>>>>>>>>>>>>>> 3. Update PolarisEvent: > >>>>>>>>>>>>>>>>>>> - Expose new requestId(), traceId(), > >>>> spanId() > >>>>>>>> methods, > >>>>>>>>>> all > >>>>>>>>>>>>>> nullable. > >>>>>>>>>>>>>>>>>>> - This would align with the emerging > >>>> consensus > >>>>>>>> around > >>>>>>>>>>>> including > >>>>>>>>>>>>>>>>>>> contextual information in PolarisEvent [1]. > >>>>>>>>>>>>>>>>>>> 4. Update events table SQL schema: > >>>>>>>>>>>>>>>>>>> - Insert the client-provided request ID > >>>> into the > >>>>>>>>>> request_id > >>>>>>>>>>>>>>>>>>> column; otherwise, insert null. > >>>>>>>>>>>>>>>>>>> - Add two new nullable columns, trace_id and > >>>>>>>> span_id, > >>>>>>>>>> and > >>>>>>>>>>>>>> populate > >>>>>>>>>>>>>>>>>>> them if OTel is enabled. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> From our discussions, I think it's important > >>>> to not > >>>>>>>>>> conflate > >>>>>>>>>>>> OTel > >>>>>>>>>>>>>>>>>>> tracing fields with Envoy tracing fields, > >>>> which is > >>>>>> why > >>>>>>>> I > >>>>>>>>>>>> suggest we > >>>>>>>>>>>>>>>>>>> use separate fields / columns for them. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Would the above plan work for everyone? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> Alex > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> [1]: > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://lists.apache.org/thread/rl5cpcft16sn5n00mfkmx9ldn3gsqtfy%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw02wPvb0qxRzYAKEP0h8l9T%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw3AIjY12CwTp7ItIvzTOIIN&source=gmail-imap&ust=1762469626000000&usg=AOvVaw0O6N5bjiJtEUkTDiZL-DlH > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Oct 24, 2025 at 9:33 AM Adnan Hemani > >>>>>>>>>>>>>>>>>>> <[email protected]> wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks to Alex for starting this thread - > >>>> because > >>>>>> of > >>>>>>>>>> this, I’m > >>>>>>>>>>>>>> just > >>>>>>>>>>>>>>>>>>> coming to the realization that OTel Trace and > >>>> Span > >>>>>> IDs > >>>>>>>>> are > >>>>>>>>>>>> coming > >>>>>>>>>>>>>> built-in > >>>>>>>>>>>>>>>>>>> with Quarkus and my previous work to generate a > >>>>>>>>>>>>>> Request/Correlation ID is > >>>>>>>>>>>>>>>>>>> likely not needed as a result. My original > >>>>>> motivation > >>>>>>>> for > >>>>>>>>>>>>>> generation of a > >>>>>>>>>>>>>>>>>>> Request/Correlation ID was to ensure that any > >>>>>> client > >>>>>>>> can > >>>>>>>>>>>> uniquely > >>>>>>>>>>>>>> identify > >>>>>>>>>>>>>>>>>>> a request made to Polaris, which would be > >>>>>> especially > >>>>>>>>>> useful for > >>>>>>>>>>>>>> debugging > >>>>>>>>>>>>>>>>>>> failing requests or identifying call patterns. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> As a result, I’m a +1 on Michael’s opinion: we > >>>>>> should > >>>>>>>>>> remove > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> Request/Correlation ID generation and always > >>>> use > >>>>>> the > >>>>>>>> OTel > >>>>>>>>>>>>>> trace/span IDs > >>>>>>>>>>>>>>>>>>> (which come for free with Quarkus) instead for > >>>> the > >>>>>>>>>> Correlation > >>>>>>>>>>>> ID > >>>>>>>>>>>>>> unless a > >>>>>>>>>>>>>>>>>>> valid header is present, which would take over > >>>> as > >>>>>> the > >>>>>>>>>>>> Correlation > >>>>>>>>>>>>>> ID > >>>>>>>>>>>>>>>>>>> instead. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> — > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> To answer Dmitri’s question re Polaris > >>>> Events: The > >>>>>>>>>> intended > >>>>>>>>>>>> use > >>>>>>>>>>>>>> case is > >>>>>>>>>>>>>>>>>>> to provide some sort of correlation between > >>>> events > >>>>>> that > >>>>>>>>>> have > >>>>>>>>>>>>>> occurred as > >>>>>>>>>>>>>>>>>>> part of the same request. For example, if a > >>>> user > >>>>>> makes > >>>>>>>> an > >>>>>>>>>>>>>> CommitTransaction > >>>>>>>>>>>>>>>>>>> request, it would be helpful to see all > >>>> UpdateTable > >>>>>>>> calls > >>>>>>>>>> that > >>>>>>>>>>>>>> were made as > >>>>>>>>>>>>>>>>>>> part of that one user request. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>>>>> Adnan Hemani > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Oct 23, 2025, at 12:15 PM, Dmitri > >>>>>> Bourlatchkov < > >>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi Michael, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Logging x-request-id headers makes sense. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Just to confirm: if / when we restore that, > >>>>>> Polaris > >>>>>>>>> will > >>>>>>>>>> NOT > >>>>>>>>>>>>>> generate > >>>>>>>>>>>>>>>>>>> new > >>>>>>>>>>>>>>>>>>>>> IDs in case the header is not present in the > >>>>>> request, > >>>>>>>>>>>> correct? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> I believe x-request-id can co-exist with > >>>> OTel. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> What about adding request IDs to events > >>>> [1][2]? > >>>>>>>> What's > >>>>>>>>>> the > >>>>>>>>>>>>>> intended use > >>>>>>>>>>>>>>>>>>>>> case for that? Could you share some context > >>>> here > >>>>>> too? > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Side note: I proposed [2877] flagging event > >>>>>>>> persistence > >>>>>>>>>> as > >>>>>>>>>>>>>> "beta" in > >>>>>>>>>>>>>>>>>>>>> 1.2.0... This discussion adds another point > >>>>>> towards > >>>>>>>>>> that, I > >>>>>>>>>>>>>> think. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> [1] > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://github.com/apache/polaris/blob/2f0c7a43d446452004ea51196b618de9bdf0e25b/runtime/service/src/main/java/org/apache/polaris/service/events/listeners/inmemory/InMemoryBufferEventListener.java%25252523L97%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw1WfUaXLp6z_M87iAXEqSUw%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw1Pioys4ROm8vYM_mdx4ygH%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw39NasMg4Tgyrfe5Bj_U4xY&source=gmail-imap&ust=1762469626000000&usg=AOvVaw0sDeqLAsJrlT0vl5OSGLZC > >>>>>>>>>>>>>>>>>>>>> [2] > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://github.com/apache/polaris/blob/19742cc20f4bc0b7e5a315a62f89c6085ad81b7d/runtime/service/src/main/java/org/apache/polaris/service/events/listeners/PolarisPersistenceEventListener.java%25252523L66%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw12-7e3ahm2sLSkLSNqTecm%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw1PGW6uFwtUN8F1dOlJwrpm%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw3y_SObfpEJH_K_8RD9lVTL&source=gmail-imap&ust=1762469626000000&usg=AOvVaw0Iwahb3E3xhtLPtdPmqs1i > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> [2877] > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://github.com/apache/polaris/pull/2877%25252523discussion_r2456300613%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw3TuYbkzwnLx3QEVIM8oDda%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw2Tfk7wAM1MaB5z9Dvw5X5H%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw2_e3B3qU8kJxdMmQx-q6bZ&source=gmail-imap&ust=1762469626000000&usg=AOvVaw3BMSIO2LpE1BaeIgK-c9nY > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> Dmitri. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Thu, Oct 23, 2025 at 2:23 PM Michael > >>>> Collado < > >>>>>>>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Hey Dmitri > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> The generating a request id is new code > >>>> that was > >>>>>>>> added > >>>>>>>>>>>> after the > >>>>>>>>>>>>>>>>>>> original > >>>>>>>>>>>>>>>>>>>>>> x-request-id support. You can see the state > >>>>>> from ~1 > >>>>>>>>> year > >>>>>>>>>>>> ago, we > >>>>>>>>>>>>>>>>>>> hard-coded > >>>>>>>>>>>>>>>>>>>>>> request_id as the header we used for the > >>>> MDC - > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://github.com/apache/polaris/blob/a6197bd7d8cb5551253fa427e4373897205ecece/polaris-service/src/main/java/org/apache/polaris/service/PolarisApplication.java%25252523L415-L416%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw35Q1A_2avAiSYlYVAnZxBb%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw34DksOw7DSHJu8PfQQ5bT6%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw1g09FwhrTquJs9utV9CAX9&source=gmail-imap&ust=1762469626000000&usg=AOvVaw0dwBsX019LeuexMDdck0dM > >>>>>>>>>>>>>>>>>>>>>> . At some point, it was changed to be > >>>>>> configurable, > >>>>>>>>>> then the > >>>>>>>>>>>>>>>>>>>>>> ContextResolverFilter filter was > >>>>>>>> refactored/eliminated > >>>>>>>>>> and > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> RequestIdFilter took its responsibility, but > >>>>>> lost > >>>>>>>> some > >>>>>>>>>> of > >>>>>>>>>>>> its > >>>>>>>>>>>>>> original > >>>>>>>>>>>>>>>>>>>>>> functionality. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> My personal opinion is that restoring > >>>> support > >>>>>> for > >>>>>>>> the > >>>>>>>>>>>>>> x-request-id > >>>>>>>>>>>>>>>>>>> header > >>>>>>>>>>>>>>>>>>>>>> is something that we should do, but if the > >>>>>> header > >>>>>>>>> isn't > >>>>>>>>>>>> present, > >>>>>>>>>>>>>>>>>>> falling > >>>>>>>>>>>>>>>>>>>>>> back on simply using OTel trace ids is good > >>>>>> enough > >>>>>>>>>> (better, > >>>>>>>>>>>>>> even) than > >>>>>>>>>>>>>>>>>>>>>> generating another random request id. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Mike > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 23, 2025 at 10:47 AM Dmitri > >>>>>>>> Bourlatchkov < > >>>>>>>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Hi Michael, > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks for the info! > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Working with Envoy's tracing headers makes > >>>>>> sense to > >>>>>>>>> me. > >>>>>>>>>>>>>> However, I > >>>>>>>>>>>>>>>>>>>>>> wonder: > >>>>>>>>>>>>>>>>>>>>>>> why would Polaris need to generate a new > >>>>>> request ID > >>>>>>>>>> inside > >>>>>>>>>>>> its > >>>>>>>>>>>>>>>>>>> code?.. > >>>>>>>>>>>>>>>>>>>>>>> and return it in response headers? > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> How important is it to propagate this ID to > >>>>>> Polaris > >>>>>>>>>> Events? > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> I'm just trying to understand the full > >>>> context > >>>>>> :) > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>> Dmitri. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 23, 2025 at 1:29 PM Michael > >>>>>> Collado < > >>>>>>>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I think the original intention for this > >>>>>> requestId > >>>>>>>>>> field > >>>>>>>>>>>> was to > >>>>>>>>>>>>>>>>>>> support > >>>>>>>>>>>>>>>>>>>>>>>> request propagation from load balancers, > >>>> like > >>>>>>>> Envoy > >>>>>>>>> ( > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw1RnuM8mViV-j7jvuxq74Aw%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw3LNqtilZ2OoJfE7yEwraZa%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw2hTMXu2DU30Lg_5UBzsDJw&source=gmail-imap&ust=1762469626000000&usg=AOvVaw3EG5R-XtDVNQoOZTJYC4BU > >>>>>>>>>>>>>>>>>>>>>>>> ), which is distinct from OTEL. Don't ask > >>>> me > >>>>>> why > >>>>>>>> the > >>>>>>>>>>>> default > >>>>>>>>>>>>>>>>>>>>>>>> is Polaris-Request-Id - I think it was > >>>>>> originally > >>>>>>>> a > >>>>>>>>>> custom > >>>>>>>>>>>>>> thing, > >>>>>>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>>>>>>> then > >>>>>>>>>>>>>>>>>>>>>>>> we changed to integrate with existing > >>>>>> conventions. > >>>>>>>>>>>>>> Unfortunately, > >>>>>>>>>>>>>>>>>>>>>> looking > >>>>>>>>>>>>>>>>>>>>>>>> through the code, I think that the actual > >>>>>>>> functional > >>>>>>>>>>>> plumbing > >>>>>>>>>>>>>> has > >>>>>>>>>>>>>>>>>>> been > >>>>>>>>>>>>>>>>>>>>>>> lost > >>>>>>>>>>>>>>>>>>>>>>>> in the course of multiple refactors > >>>> around the > >>>>>>>> call > >>>>>>>>>>>> context > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>> resolver. I > >>>>>>>>>>>>>>>>>>>>>>>> don't see references to that property or > >>>> the > >>>>>>>>>> underlying > >>>>>>>>>>>>>> header. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Support for the unofficial x-request-id > >>>> header > >>>>>>>> feels > >>>>>>>>>> like > >>>>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>> should definitely keep, especially when > >>>>>> Polaris is > >>>>>>>>> one > >>>>>>>>>>>>>> service in a > >>>>>>>>>>>>>>>>>>>>>> mesh > >>>>>>>>>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>>>>>>>> services that maybe don't have OTel > >>>>>> integration. > >>>>>>>>> I'm a > >>>>>>>>>>>> fan of > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> OTel > >>>>>>>>>>>>>>>>>>>>>>>> standard, but it's not entirely > >>>> ubiquitous and > >>>>>>>> there > >>>>>>>>>> are > >>>>>>>>>>>> many > >>>>>>>>>>>>>>>>>>>>>> middleware > >>>>>>>>>>>>>>>>>>>>>>>> layers that know how to forward on the > >>>>>>>> x-request-id > >>>>>>>>>>>> header. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Mike > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 23, 2025 at 3:00 AM Robert > >>>> Stupp < > >>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Yes, we should aim for interoperability > >>>> with > >>>>>> the > >>>>>>>>>> existing > >>>>>>>>>>>>>> de-facto > >>>>>>>>>>>>>>>>>>>>>>>>> standard OTel and make it easy for users > >>>> to > >>>>>>>>> integrate > >>>>>>>>>>>> into > >>>>>>>>>>>>>> their > >>>>>>>>>>>>>>>>>>>>>>>>> observability platforms. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Oct 22, 2025 at 7:05 PM Dmitri > >>>>>>>>> Bourlatchkov < > >>>>>>>>>>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Alex and All, > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> I certainly support the idea of > >>>> following > >>>>>> OTel > >>>>>>>>>>>> standards for > >>>>>>>>>>>>>>>>>>>>>>> achieving > >>>>>>>>>>>>>>>>>>>>>>>>>> "correlation" wrt Polaris requests > >>>> and/or > >>>>>>>> events. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> As to what form the correlation data > >>>> should > >>>>>>>> take, > >>>>>>>>> I > >>>>>>>>>>>> believe > >>>>>>>>>>>>>> it is > >>>>>>>>>>>>>>>>>>>>>>>>>> conceptually what the OTel "context" > >>>>>> represents. > >>>>>>>>>> So, I > >>>>>>>>>>>>>> believe it > >>>>>>>>>>>>>>>>>>>>>>> makes > >>>>>>>>>>>>>>>>>>>>>>>>>> sense for Polaris to support standard > >>>>>> context > >>>>>>>>>>>> propagators > >>>>>>>>>>>>>> at the > >>>>>>>>>>>>>>>>>>>>>> API > >>>>>>>>>>>>>>>>>>>>>>>>> layer. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> If the incoming request has OTel context > >>>>>>>>>> information, > >>>>>>>>>>>> then > >>>>>>>>>>>>>>>>>>>>>> returning > >>>>>>>>>>>>>>>>>>>>>>>> any > >>>>>>>>>>>>>>>>>>>>>>>>>> other "correlation" data in the > >>>> response is > >>>>>>>>>> redundant, I > >>>>>>>>>>>>>> think. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> If the incoming request does not have > >>>> OTel > >>>>>>>> context > >>>>>>>>>> info, > >>>>>>>>>>>>>> what is > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>> purpose of generating a Polaris-specific > >>>>>>>>>> "correlation > >>>>>>>>>>>> ID"? > >>>>>>>>>>>>>> How is > >>>>>>>>>>>>>>>>>>>>>> it > >>>>>>>>>>>>>>>>>>>>>>>>>> envisioned to be used? > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> If the intention is to correlate a > >>>> Polaris > >>>>>>>>> response > >>>>>>>>>>>>>> (operation) > >>>>>>>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>>>>>>> events > >>>>>>>>>>>>>>>>>>>>>>>>>> that might have resulted from its > >>>>>> execution, I > >>>>>>>>>> believe a > >>>>>>>>>>>>>> more > >>>>>>>>>>>>>>>>>>>>>> robust > >>>>>>>>>>>>>>>>>>>>>>>>>> approach would be to propagate the OTel > >>>>>> trace > >>>>>>>> info > >>>>>>>>>>>>>> (starting a new > >>>>>>>>>>>>>>>>>>>>>>>> trace > >>>>>>>>>>>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>>>>>>>>> necessary) into event data. Then, > >>>> Polaris > >>>>>> can > >>>>>>>> also > >>>>>>>>>>>> return > >>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>> trace > >>>>>>>>>>>>>>>>>>>>>>>>> context > >>>>>>>>>>>>>>>>>>>>>>>>>> in the API response (top span). It's a > >>>> bit > >>>>>>>> awkward > >>>>>>>>>> from > >>>>>>>>>>>> the > >>>>>>>>>>>>>> OTel > >>>>>>>>>>>>>>>>>>>>>>>>>> perspective, but might be an option for > >>>>>>>> supporting > >>>>>>>>>>>> custom > >>>>>>>>>>>>>>>>>>>>>>> correlators. > >>>>>>>>>>>>>>>>>>>>>>>> It > >>>>>>>>>>>>>>>>>>>>>>>>>> could be covered by a feature flag. The > >>>>>> header > >>>>>>>>> name > >>>>>>>>>>>> could be > >>>>>>>>>>>>>>>>>>>>>>>>>> "polaris-traceparent" for W3C Trace > >>>> Context. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Custom correlation code will be able to > >>>>>> extract > >>>>>>>>> the > >>>>>>>>>>>> trace > >>>>>>>>>>>>>> ID from > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>>>> response and from events and find > >>>> related > >>>>>> data. > >>>>>>>>>>>> Granted, it > >>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>>>>>>>> require > >>>>>>>>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>>>>>>>>> bit more effort for the custom code to > >>>>>> decode > >>>>>>>>> trace > >>>>>>>>>> IDs > >>>>>>>>>>>>>> from the > >>>>>>>>>>>>>>>>>>>>>> OTel > >>>>>>>>>>>>>>>>>>>>>>>>>> context, but the format is standard and > >>>> not > >>>>>>>>>> complex. The > >>>>>>>>>>>>>> benefit > >>>>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>>>> Polaris, though, is that it can easily > >>>>>> integrate > >>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>>>> OTel-compatible > >>>>>>>>>>>>>>>>>>>>>>>>>> observability platforms regardless of > >>>>>> whether > >>>>>>>> any > >>>>>>>>>>>> particular > >>>>>>>>>>>>>>>>>>>>>>> deployment > >>>>>>>>>>>>>>>>>>>>>>>>>> uses custom correlators or not. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> WDYT? > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>> Dmitri. > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Oct 22, 2025 at 6:03 AM > >>>> Alexandre > >>>>>> Dutra > >>>>>>>> < > >>>>>>>>>>>>>>>>>>> [email protected] > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Today, Polaris has the notion of > >>>> "request > >>>>>> ID", > >>>>>>>>> but > >>>>>>>>>> its > >>>>>>>>>>>>>> purpose is > >>>>>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>>>>>>> entirely clear. It seems to serve as an > >>>>>>>>>> observability > >>>>>>>>>>>>>> feature to > >>>>>>>>>>>>>>>>>>>>>>>>>>> facilitate correlation. A pending PR > >>>> aims > >>>>>> to > >>>>>>>>>> rename it > >>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>> "correlation > >>>>>>>>>>>>>>>>>>>>>>>>>>> ID" for better alignment with industry > >>>>>>>> standards > >>>>>>>>>> [1]. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> However, this PR has brought to light > >>>>>> overlaps > >>>>>>>>> with > >>>>>>>>>>>> core > >>>>>>>>>>>>>>>>>>>>>> telemetry > >>>>>>>>>>>>>>>>>>>>>>>>>>> features: when OpenTelemetry (OTel) is > >>>>>> enabled > >>>>>>>> in > >>>>>>>>>>>> Polaris, > >>>>>>>>>>>>>> each > >>>>>>>>>>>>>>>>>>>>>>>>>>> request already has a trace ID and > >>>> span ID, > >>>>>>>>> making > >>>>>>>>>> a > >>>>>>>>>>>>>> separate > >>>>>>>>>>>>>>>>>>>>>>>>>>> correlation ID redundant. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Moreover, using the OTel trace ID and > >>>> span > >>>>>> ID > >>>>>>>> in > >>>>>>>>>>>> Polaris > >>>>>>>>>>>>>> events, > >>>>>>>>>>>>>>>>>>>>>>>>>>> rather than the generated correlation > >>>> ID, > >>>>>> would > >>>>>>>>>>>>>> significantly > >>>>>>>>>>>>>>>>>>>>>>>> simplify > >>>>>>>>>>>>>>>>>>>>>>>>>>> correlation of events with other > >>>> traces. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore, I propose the following > >>>> changes: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> 1. If OTel is enabled, use the trace > >>>> ID and > >>>>>>>> span > >>>>>>>>>> ID as > >>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>>> correlation > >>>>>>>>>>>>>>>>>>>>>>>>>>> ID for the request, instead of > >>>> generating a > >>>>>>>>> random > >>>>>>>>>>>>>> correlation > >>>>>>>>>>>>>>>>>>>>>> ID. > >>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Otherwise, if a (Polaris-specific) > >>>>>>>> correlation > >>>>>>>>>> ID > >>>>>>>>>>>>>> header is > >>>>>>>>>>>>>>>>>>>>>>>> present > >>>>>>>>>>>>>>>>>>>>>>>>>>> in the request, use it. > >>>>>>>>>>>>>>>>>>>>>>>>>>> 3. If neither of the above conditions > >>>> is > >>>>>> met, > >>>>>>>>>> generate > >>>>>>>>>>>> a > >>>>>>>>>>>>>> random > >>>>>>>>>>>>>>>>>>>>>>>>>>> correlation ID. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I am somewhat undecided on the best > >>>>>> approach > >>>>>>>>> when a > >>>>>>>>>>>>>> correlation > >>>>>>>>>>>>>>>>>>>>>> ID > >>>>>>>>>>>>>>>>>>>>>>>>>>> header is present in the request. > >>>> However, > >>>>>> I > >>>>>>>>>> believe it > >>>>>>>>>>>>>> would be > >>>>>>>>>>>>>>>>>>>>>>> more > >>>>>>>>>>>>>>>>>>>>>>>>>>> sensible to disregard it if OTel is > >>>>>> enabled, as > >>>>>>>>>> OTel > >>>>>>>>>>>>>> offers a > >>>>>>>>>>>>>>>>>>>>>> more > >>>>>>>>>>>>>>>>>>>>>>>>>>> robust solution for client-to-server > >>>> trace > >>>>>>>>>> propagation, > >>>>>>>>>>>>>> e.g. W3C > >>>>>>>>>>>>>>>>>>>>>>>> Trace > >>>>>>>>>>>>>>>>>>>>>>>>>>> Context propagation [2]. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Please share your thoughts! > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>> Alex > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> [1]: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://github.com/apache/polaris/pull/2757%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw1-kAWfEk4tmsEg0q0GZBCn%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw1Oe-25vtt4gLVSMFMtSVNg%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw2ohYKOQ8XU5-GBlDo6zYGC&source=gmail-imap&ust=1762469626000000&usg=AOvVaw38kU5KZM7IlDD0Y7UPVYn5 > >>>>>>>>>>>>>>>>>>>>>>>>>>> [2]: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://www.google.com/url?q%253Dhttps://www.google.com/url?q%25253Dhttps://www.w3.org/TR/trace-context%252526source%25253Dgmail-imap%252526ust%25253D1761851831000000%252526usg%25253DAOvVaw22nMyOS7pbJ69XrBo5kHQS%2526source%253Dgmail-imap%2526ust%253D1761927167000000%2526usg%253DAOvVaw1TRdkzABc_7U-_KZ1MZ59v%26source%3Dgmail-imap%26ust%3D1762450034000000%26usg%3DAOvVaw0cUBLtXCkRoH5pL57naUhY&source=gmail-imap&ust=1762469626000000&usg=AOvVaw3UFfRQLLzFZTMF1vmrxROq > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > >> >
