gnodet commented on PR #22255:
URL: https://github.com/apache/camel/pull/22255#issuecomment-4125209761

   ## Analysis of removed code — historical context
   
   Checked git history to verify we're not removing something added for a good 
reason. Here's what I found:
   
   ### Key commits
   
   1. **CAMEL-21202** (Oct 2024, Adriano Machado) — Originally added 
`OpenTelemetryInstrumentedThreadPoolFactory` and `ThreadFactoryListener` to the 
**old** `camel-opentelemetry` module (now deprecated) to propagate OTel context 
across thread boundaries via `Context.taskWrapping()`.
   
   2. **CAMEL-22648** (Jan 2026, Pasquale Congiusti, `3a751cf`) — Added the 
`BAGGAGE_CAMEL_FLAG` / dirty context detection to `camel-opentelemetry2`. 
Commit message: *"We have introduced a flag which we use to control whether a 
span was generated from Camel or not. This is useful when we reuse 'dirty' 
threads which were previously asynchronously setting otel context via thread 
locals. By checking the flag we can decide to continue propagation of a trace 
from an existing span (for example, when vertx or otel agents are injecting a 
span before the Camel process kicks in)."*
   
   3. **`5810a742`** (today) — Ported thread pool instrumentation from 
deprecated module to `camel-opentelemetry2`.
   
   4. **`f60675cb`** (today, Aurélien Pupier) — Reverted that port.
   
   ### Risk assessment
   
   The `BAGGAGE_CAMEL_FLAG` was added deliberately to handle a real scenario: 
when a third-party component (like Vert.x or an OTel Java agent) sets a span in 
`Context.current()` before Camel starts processing. Without the flag, Camel 
would ignore that external root span.
   
   By always using `Context.root()`, we **ignore** any span that an OTel Java 
agent or Vert.x sets in `Context.current()` before Camel processes a message. 
Those external spans would not become parents of the Camel trace — Camel would 
start a disconnected new trace instead.
   
   However, per the design doc (`proposals/tracing.adoc`), the intended way to 
propagate that context is through Exchange headers (`traceparent`), not 
ThreadLocal. If Vert.x or an OTel agent wants to link to Camel, they should 
inject the `traceparent` header into the Exchange, which `extract()` will pick 
up from the headers.
   
   **Next step**: Investigating whether the callers (e.g., Camel Vert.x HTTP 
component, platform-http) already inject `traceparent` headers into the 
Exchange, or if they only rely on `Context.current()`. If the latter, those 
callers would need to be updated to inject headers for this approach to work 
end-to-end.
   
   _Claude Code on behalf of Guillaume Nodet_


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to