Header duplication with KafkaDelayedRetryTopic

[joystuffs]

Description

I noticed there is a header duplication using the KafkaDelayedRetryTopic, I saw there was already a discussion about it.

#2979

I see the original headers are copied in to the new retry record headers as shown below

record.getHeaders().forEach(header -> retry.headers().add(header));

I was wondering if this is the actual design, to carry the old headers along the retry records chain or if it can be simplified given that each retry record has already its own header information.

I also notice that this breaks the quarkus dev UI when I try to navigate the topic given the header duplication as mentioned in the mentioned issue.

Question

is this a expected behavior?

[cescoffier]

Yes, we want to keep the old headers as they may ease record identification.

[joystuffs]

thank fo the clarification.

[joystuffs]

@cescoffier probably not relevant but for this issue but I noticed that when the tracing-enable is enable with the DRT, no traceId/SpanId are attached to the MCD.

[cescoffier]

I don't think we write in the same duplicated context, which would explain it.

[joystuffs]

Ok. So if the MDC are cleaned up at the end of the method execution when the DRT will be trigger, no traceId and SpanId will be written.

If so, then the traceId and SpanId should be attached manually.

Please, correct me if I get it wrong

Something interesting I observed is that the retry messages have always a new trace parent header, that’s why I was wondering why these traces are not in the MDC.

[ozangunalp]

We should check two things :

• whether the retry message sender attaches the traceId to the record.
• whether the retry message retrieves the trace and creates the actual span with it.