Kafka batch mode breaks traceId continuity between producer and processor spans

[mznet]

Describe the bug

When using Kafka in batch mode, I observed that producer and processor spans are not tied together with the same traceId. However, when in single-record mode, spans are correctly linked under a shared trace context.

This result makes it difficult to achieve proper end-to-end traceability when processing messages in batches — which is a common practice in performance-sensitive systems.

This image shows the result of a test on a sample application

Steps to reproduce

1. Configure a @KafkaListener with a ConcurrentKafkaListenerContainerFactory bean.
2. Enable batch mode via:

factory.setBatchListener(true);

Expected behavior

Producer and process spans should be tied together with the shared trace context to make proper end-to-end observability as soon as possible.

Actual behavior

• On batch mode, producer and process are not tied together with one traceId, having different trace context.
• On single record mode, produce and process are tied together with one traceId.

Javaagent or library instrumentation version

v2.17.0

Environment

JDK: Eclipse Temurin 21.0.6
OS: Mac OS 15.3.1 (24D70)

Additional context

No response

[laurit]

When using batch listener producer and consumer spans will be in different traces, traces are connected with span links. Have a look at batch messaging examples at https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#batch-receiving While these don't match exactly to what we currently do they should give you an idea on what kind of traces structure to expect.