[Bug]: Context propagation not working with asynchronous request/reply

[cedric-schaller]

Bug Description

When using context propagation in the context of OpenTelemetry, the traceId and spanId are stored in the MDC and must be propagated from one thread to the other. This does not happen out of the box and needs to be done explicitly.

In RequestReplyServiceImpl, this is done on line 392, where a ContextSnapshot is made. However, the method postRequest() returns a CompletableFuture to which additional stages can (and typically will) be added by the application. In such a case, the application must be aware of context propagation issues and make a ContextSnapshot for every stage added, as it is done in RequestReplyServiceImpl. This is both cumbersome and error-prone.

There is an alternative where not the Runnable itself is wrapped with a ContextSnapshot, but the Executor. This makes sure that the context is passed on automatically to every thread used by the various CompletableFuture stages, providing a global mechanism instead of a local one.

Expected Behavior

The content of the MDC is the same when processing the request and the reply. The MDC values are passed on from one thread to the other.

Steps to Reproduce

In order to simplify the reproduction of the problem, we describe programmatic steps to do so. Adding libraries for observation will allow to reproduce the problem without doing anything programmatically.

1. In the application, set a value (like a traceId) in the MDC with MDC.put() when receiving a request.
2. Configure the logger to print that value as part of the log statement. The value is printed when processing the request, but not the response, since it is treated by another thread.

Solace Broker version

No response

Solace API

No response

Solace API version

No response

[helios57]

Hi @cedric-schaller, could you please review #56 and confirm this resolves your case?

The underlying fix actually shipped in 6.0.2: the request/reply executor is now wrapped (instead of wrapping each individual Runnable), so the captured micrometer context — e.g. the MDC carrying traceId/spanId — is restored for every stage of the pipeline, including stages your application chains onto the returned CompletableFuture. You no longer need to capture a ContextSnapshot yourself. This is exactly the "wrap the executor" approach you suggested.

#56 adds the documentation that was missing for it (a CHANGELOG 6.0.2 entry and a README section), and there are tests covering propagation to chained stages.

If you can, please verify 6.0.2+ behaves as expected on your side. Thanks for the clear write-up and the suggested solution!