propagate scope in async failures

[igormq]

Fix trace context loss in async Kafka error handling

This PR addresses an issue where the trace context is lost when handling Kafka message failures asynchronously.

Problem

When async returns are enabled and a consumer failure occurs, the trace context from the original message is not propagated. This leads to each step of the retry/DLT flow starting a new trace instead of continuing the original one.

Example (current behavior):
• Producer → trace 1
• Consumer → trace 1, fails → message goes to retry topic
• Retry listener → trace 2, fails → message goes to DLT topic
• DLT listener → trace 3

This breaks end-to-end traceability, as each listener receives a new trace ID.

Root cause

The issue stems from the handleAsyncFailure method, which runs in a different thread but does not propagate the original Observation (trace) context associated with the failed record.

Fix

Ensure that the observation context is correctly propagated when handling async failures. This preserves the trace ID across retry and DLT flows.

🔧 Tested using version 3.3.6 so I could build and validate the JAR in a real-world project.

[artembilan]

I'd like to see the fix issued against main.
And please, follow a DCO requirements.

[igormq]

I'd like to see the fix issued against main. And please, follow a DCO requirements.

done!

[artembilan]

OK. The logic is like this:

1. The MessagingMessageListenerAdapter does this in its handleResult() on the completableFutureResult.whenComplete:

				else {
					Throwable cause = t instanceof CompletionException ? t.getCause() : t;
					observation.error(cause);
					asyncFailure(request, acknowledgment, consumer, cause, source);
				}

2. That asyncFailure() calls the mentioned asyncRetryCallback with an implementation in the KafkaMessageListenerContainer like this:

		private void callbackForAsyncFailure(ConsumerRecord<K, V> cRecord, RuntimeException ex) {
			this.failedRecords.addLast(new FailedRecordTuple<>(cRecord, ex));
		}

3. We probably can propagate that observation from the handleResult() down to the asyncFailure. Open scope there.
4. And get access to the currentObservation from the mentioned callbackForAsyncFailure to be populated to that FailedRecordTuple.
5. This way KafkaMessageListenerContainer.handleAsyncFailure() would be able to restore an observation from the tuple to in that invokeErrorHandlerBySingleRecord().

Not sure if that is a goal of your solution.
WDYT?

[igormq]

@artembilan , does it make sense what i did?

OK. The logic is like this:

1. The MessagingMessageListenerAdapter does this in its handleResult() on the completableFutureResult.whenComplete:

				else {
					Throwable cause = t instanceof CompletionException ? t.getCause() : t;
					observation.error(cause);
					asyncFailure(request, acknowledgment, consumer, cause, source);
				}

2. That asyncFailure() calls the mentioned asyncRetryCallback with an implementation in the KafkaMessageListenerContainer like this:

		private void callbackForAsyncFailure(ConsumerRecord<K, V> cRecord, RuntimeException ex) {
			this.failedRecords.addLast(new FailedRecordTuple<>(cRecord, ex));
		}

3. We probably can propagate that observation from the handleResult() down to the asyncFailure. Open scope there.
4. And get access to the currentObservation from the mentioned callbackForAsyncFailure to be populated to that FailedRecordTuple.
5. This way KafkaMessageListenerContainer.handleAsyncFailure() would be able to restore an observation from the tuple to in that invokeErrorHandlerBySingleRecord().

Not sure if that is a goal of your solution. WDYT?

@artembilan thank you a lot for the feedback. this is exactly what i was trying to achieve! made the changes accordingly!