Messages Stuck in RabbitMQ after NSB Deployment with new Version Number

1

I am not a newbie, but I don’t remember this being such an issue in the past.

We use CICD for deployments when a new PR in Github gets approved, it is in production a small window of time.

If there are any messages pending in the queue from the prior deployment that are versioned as 1.2.3.4 and the CICD (continuous integration continue deployment) process deploys version 1.2.3.5 … all pending items in the queue are orphaned. They never get processed and new messages are process either. (because there are too many to see the new ones with the new version number)

Can you tell the transport to ignore the version number in the serialization?

type: BAI_Messages.Process_Generic_BAIFileMessage
message_id: ccaed9c0-9935-4061-a0bd-aaf500a9d216
reply_to: PROD_nsb_bai
correlation_id: 129b687d-8931-4629-9cc9-aaf500a96bc2
delivery_mode: 2
headers:
$.diagnostics.originating.hostid: 9795063be47754e8b96c93c44056bd0f
NServiceBus.ContentType: application/json
NServiceBus.ConversationId: c11f4863-7fde-4e83-b995-aaf500a96bc2
NServiceBus.CorrelationId: 129b687d-8931-4629-9cc9-aaf500a96bc2
NServiceBus.EnclosedMessageTypes: BAI_Messages.Process_Generic_BAIFileMessage, BAI_Messages_NetStandard, Version=2019.44.3.0, Culture=neutral, PublicKeyToken=null;BAI_Messages.ProcessBAIFileMessage, BAI_Messages_NetStandard, Version=2019.44.3.0, Culture=neutral, PublicKeyToken=null
NServiceBus.MessageId: ccaed9c0-9935-4061-a0bd-aaf500a9d216
NServiceBus.MessageIntent: Send
NServiceBus.OriginatingEndpoint: PROD_nsb_bai
NServiceBus.OriginatingMachine: DG-PROD-WEB
NServiceBus.RelatedTo: 129b687d-8931-4629-9cc9-aaf500a96bc2
NServiceBus.ReplyToAddress: PROD_nsb_bai
NServiceBus.TimeSent: 2019-10-29 10:18:17:886463 Z
NServiceBus.Transport.RabbitMQ.ConfirmationId: 24
NServiceBus.Version: 7.1.10
content_type: application/json
2

David,

What transport are you on?

Do you really need to version the message assembly? The simplest way is to treat the messaging assembly with a fixed version number that only increases when you really need to (I can’t think of many). Message contractscan follow a different versioning schema.

Another option is to have an outgoing behavior that strips out the version as shown here Consumer-driven Contracts sample • NServiceBus Samples • Particular Docs. But I personally would go with the first approach to treat the version of the message assemblies more or less stable

Hope that helps

Daniel