fix: interceptor preventing metadata propagation

[holomekc]

I am not 100% sure about this, but at the moment it is not possible to access the OutgoingMessageMetadata (omd) in case an interceptor is used. Is this intended? I am also not sure if the approach to access the omd I used in the test is actually something you guys had in mind.

Nevertheless, at the moment the OutgoingInterceptorDecorator is overwriting the omd without checking if the meta data already exists

[ozangunalp]

I didn't think of the scenario where an OutgoingMessageMetadata object instance can be reused. Overall it doesn't make a nydifference.

[holomekc]

Hi @ozangunalp ,
thx for the quick answer. Hmm I am not sure if I understand you correctly. I was trying to figure out how I can even access the OutgoingMessageMetadata in my application code, to get access to the result (For access tosqs messageId) . I couldn't figure out how except the way I used in the test I added here. I also could not find it in the documentation except in the Interceptor. But this is not always sufficient.

But using the approach I used in the test does not work, if the decorator overwrites the OutgoingMessageMetadata. Without this change I end up with no omd. No matter if I set the omd or if I do not set the omd beforehand.

[ozangunalp]

This definitely makes sense in the emitter use case.

@holomekc could you rewrite your commits by signing them?

[holomekc]

Hi @ozangunalp,
looks like Schrödinger's cat. Java 17 is green and yellow at the same time.

[ozangunalp]

I know, there is a quirk in the PR acceptance ruleset which doesn't recognize the required check.