gnodet commented on PR #22255:
URL: https://github.com/apache/camel/pull/22255#issuecomment-4125353490
## Investigation results
Investigated the callers to verify Exchange-header-based propagation works
end-to-end:
### How context flows in production
1. **HTTP request arrives** with `traceparent` header → Platform HTTP Vertx
(`VertxPlatformHttpSupport.populateCamelHeaders()`) / Netty HTTP
(`DefaultNettyHttpBinding.populateCamelHeaders()`) copy ALL HTTP headers into
Exchange message headers
2. **Camel Tracer** creates first span via `beginEventSpan()` →
`spanStorageManager.peek(exchange)` returns null for new exchange → `parent ==
null` branch → `extract(Context.root(), exchange.getIn().getHeaders())` picks
up `traceparent` from headers
3. Subsequent spans within the route use the Camel-managed span stack
(Exchange-based), not ThreadLocal
This confirms the design doc's approach works: context propagation via
Exchange headers is already the path used by all HTTP components.
### SpanInjection test fix
The `SpanInjection` test was:
1. **Never actually running** — class name didn't match surefire's `*Test`
convention
2. **Already broken before our changes** — when run after `AsyncCXFTest`, it
failed even with the original `BAGGAGE_CAMEL_FLAG` code
3. **Testing the wrong thing** — used `span.makeCurrent()` (ThreadLocal)
instead of `traceparent` header to simulate external parent spans
Root cause of the inter-test failure: `AsyncCXFTest` leaks a span into
`Context.current()` on the test thread. The test's
`spanBuilder("mySpan").startSpan()` then inherits this stale trace ID (OTel
default behavior), causing all 10 exchanges to share the same trace.
**Fix applied:**
- Renamed to `SpanInjectionTest` (now runs in CI — adds 2 tests to the suite)
- Uses `traceparent` Exchange header instead of ThreadLocal
- Uses `setNoParent()` on test span builders to avoid stale
`Context.current()` contamination
- All 14 tests pass including after async tests
_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]
