Manipulation of headers (adding a new one) inside CustomMessageIdStrategy no longer works in NServiceBus 7.1


(Marin Stavrev) #1


We have an old solution running on top of NServiceBus 5.2.6/NServiceBus.RabbitMQ 3.5.2.
It has a custom CustomMessageIdStrategy registered on the RabbitMQ transport that is used to copy the value of the UserId property (if exists) from the BasicProperties of the incoming RabbitMQ message onto a custom header entry of the message. The handler then is able to inspect the the value of the custom header and make some decision based on it.

We are aiming to upgrade to the latest NServiceBus version. Doing some tests with NServiceBus 7.1.6/NServiceBus.RabbitMQ 5.0.2 it seems the same approach does no longer work. The CustomMessageIdStrategy is being invoked as usual, however, it looks like the custom header that is added does not “survive” and reach the handler being called afterwards in the pipeline.

I also tried implementing and using IMutateIncomingMessages/IMutateIncomingTransportMessages interfaces. They get called as expected, but the RabbitMQ BasicProperties are not available on neither of those, so it is impossible to achieve what was working with NServiceBus 5.2.6 CustomMessageIdStrategy.

How can I achieve the same thing on latest NServiceBus runtime?

Best Regards
M. Stavrev

(Andreas Öhlund) #2

Hi Marin!

I can confirm that this used to work in v5 due to the loophole with the custom message id strategy that you mention. We haven’t been able to find a workaround but the use case that you mention is valid so I have raised to track giving you a way to acheive this.

What are your timeline for the upgrade?



(Marin Stavrev) #3


Thanks for the reply. Our upgrade timeline is not yet fully determined (at least 1 to 1.5 months), but we are actively working on it. I looked at the source code and saw why the “loop-hole” no longer works.

For our internal development, I’ve added as a second parameter to the messageIdStrategy Func the headers dictionary, so my custom callback can have access to it and create the necessary header based on the BasicDeliverEventArgs. I’ve compiled an internal version and moved on with the rest of the modifications.

I clearly understand what I did is not good and most likely the transport has to provide an additional hook for this purpose alone.
Even better, may be the transport abstraction should provide a generic mutator/behaviour/callback that can be inserted on the demarcation line between specific transport and the rest of NServiceBus for exactly that purpose - to do some processing on the message received from the native transport pump that can affect the produced transport-agnostic message context.

Once there is a solution available, we’ll update our implementation accordingly.

Best Regards
M. Stavrev