Hi all, it's preferable to have one correlation-ID, not two as today. So +1 on using the OTel one.
Robert On Wed, Oct 22, 2025 at 12:03 PM 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://github.com/apache/polaris/pull/2757 > [2]: https://www.w3.org/TR/trace-context
