[jira] [Commented] (CAMEL-22385) OpenTelemetry: Unclosed Span Scope with Parallel Multicast

["Sergi Mola (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-22385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016796#comment-18016796 ] 

Sergi Mola commented on CAMEL-22385:
------------------------------------

Here are some logs from setting opentelemetry to debug:

```

2025-08-28T13:50:58.200Z Camel (camel-1) thread #6 - Multicast DEBUG i.o.s.t.SdkSpan | Ignoring setStatus() description since status is not ERROR. 
2025-08-28T13:50:58.202Z Camel (camel-1) thread #6 - Multicast DEBUG i.o.c.ThreadLocalContextStorage |  Trying to close scope which does not represent current context. Ignoring the call. 
2025-08-28T13:50:58.203Z Camel (camel-1) thread #6 - Multicast DEBUG i.o.c.ThreadLocalContextStorage |  Trying to close scope which does not represent current context. Ignoring the call. 
2025-08-28T13:50:58.203Z Camel (camel-1) thread #6 - Multicast DEBUG i.o.c.ThreadLocalContextStorage |  Trying to close scope which does not represent current context. Ignoring the call. 

```

> OpenTelemetry: Unclosed Span Scope with Parallel Multicast
> ----------------------------------------------------------
>
>                 Key: CAMEL-22385
>                 URL: https://issues.apache.org/jira/browse/CAMEL-22385
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-opentelemetry
>    Affects Versions: 4.14.0
>         Environment: Here's my configuration:
> ```
> @Override
> public void configure() {
>   // 1. Consume messages from a starting endpoint
>   from(RouteEndpoints.INBOUND_ENDPOINT.getValue())
>     .routeId("MyBusinessLogicRoute")
>     // 2. Validate the incoming message
>     .choice()
>       // A generic predicate checks for validity
>       .when(header("isValid").isEqualTo(false))
>         .log("Invalid message received. Routing to dead-letter queue.")
>         .to(RouteEndpoints.DLQ_ENDPOINT.getValue()) // Send to Dead Letter Queue
>       .otherwise()
>         // 3. Route the message based on its type
>         .choice()
>           // Check for a specific "type" field in the JSON body
>           .when().jsonpath("$[?(@.messageType == 'Confirmation')]")
>             .to(RouteEndpoints.STORE_ENDPOINT.getValue()) // Store confirmation events
>           .otherwise()
>             // 4. Process other events in parallel
>             .multicast()
>               .parallelProcessing()
>               // Send to two different endpoints simultaneously
>               .to(RouteEndpoints.SEND_ENDPOINT.getValue(),
>                   RouteEndpoints.STORE_ENDPOINT.getValue())
>             .end() // Closes the multicast
>         .end() // Closes the inner choice
>     .end(); // Closes the outer choice
> ```
>            Reporter: Sergi Mola
>            Assignee: Pasquale Congiusti
>            Priority: Major
>              Labels: opentelemetry, telemetry, trace, tracing
>         Attachments: with_parallel_processing.png, without_parallel_processing.png
>
>
> I'm encountering a tracing issue with the {{camel-opentelemetry2}} component, specifically when using a {{multicast}} EIP with {{{}parallelProcessing{}}}.
> *Problem:* The root {{Span}} for my SQS-triggered route is failing to close. I believe this is because the {{Scope}} associated with this span is not being properly closed and detached from the thread after the {{multicast}} with {{parallelProcessing}} completes.
> *Observed Behavior:*
>  # *Leaked Trace Context:* Due to the unclosed scope, subsequent, unrelated spans (in this case SQS reads ) are incorrectly attached to the trace of the completed route.
>  # *Cycle Repetition:* This behavior persists until a new message is consumed from the SQS queue, which starts a new trace. However, this new trace then suffers from the same issue.
> *Key Finding:* The tracing behaves as expected (the root span's scope is closed correctly) if {{parallelProcessing}} is removed from the {{{}multicast{}}}.
> This suggests an issue with how the OpenTelemetry tracer handles the thread context lifecycle during asynchronous, parallel processing. I've attached screenshots illustrating the difference.
>  
> See attached screenshots.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)