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

   ## Closing this PR
   
   After investigation and feedback from @squakez (the camel-opentelemetry2 
author), this PR is incorrect:
   
   1. **The \`BAGGAGE_CAMEL_FLAG\` / \`Context.current()\` fallback is 
intentional** — it handles the case where an external component (Vert.x, OTel 
Java agent, Quarkus) sets a span in \`Context.current()\` before Camel 
processes a message via direct in-process call (no HTTP boundary, no 
\`traceparent\` header). Removing it would break trace linkage in this 
scenario. See [PR #20720](https://github.com/apache/camel/pull/20720).
   
   2. **The thread pool wrapping (\`Context.taskWrapping()\`) is not needed** — 
the design explicitly uses Exchange headers for context propagation, not 
ThreadLocal. This was already correctly reverted in #22254.
   
   3. **The JIRA (CAMEL-23225) appears invalid** — commented on the issue 
recommending closure. The \`camel-opentelemetry2\` design handles cross-thread 
propagation via Exchange headers, and the \`BAGGAGE_CAMEL_FLAG\` handles the 
in-process edge case. No Spring Boot \`TaskDecorator\` is needed either.
   
   **The one valid fix from this PR**: the \`SpanInjection\` test was never 
running (class name didn't match surefire \`*Test\` convention) and tested 
ThreadLocal propagation instead of header-based. Will submit that as a separate 
small PR if desired.
   
   _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