MassTransit–Message versioning

MassTransit dedicated a whole documentation page to message versioning but it still wasn’t completely clear to me how it worked.

Let’s use this blog post to see what’s going on…

Publishing messages

Let’s first focus on the sending side.

Publishing a first version of our message contract

We’ll start with a first version of our message contract:

Let’s send this to RabbitMQ using:

Time to open the RabbitMQ Management portal and take a look how the message payload is constructed:

Creating a second version of our message contract

Let’s introduce a v2 version of our message contract:

If we send it to RabbitMQ in the same way:

There isn’t such a big difference when comparing the payloads:

The ‘messagetype’ value is different and of course the message itself. But that’s it.

Send a backwards compatible version

Let’s now construct a message that implements both contracts:

And send that one:

If we now check the payload, we see that 1 message is put on the queue with the following payload:

Take a look at the ‘messagetype’. You can see that it contains both the 2 messagecontracts AND the concrete message type we created:

"messageType": [

    "urn:message:Sender:Program+SubmitOrderCommand",

    "urn:message:Messages:SubmitOrder",

    "urn:message:Messages:SubmitOrderV2"

  ],

Consuming messages

Now we have a good understanding on what is going on at the sending side, let’s move on to the consuming side.

Consuming v1 of our message contract

Let’s create a consumer for that consumes v1 of our message contract:

And subscribe this consumer:

After publishing a ‘SubmitOrder’ message, our consumer is called as expected.

> Old Order consumed

Consuming v2 of our message contract

Let’s create a consumer for that consumes v2 of our message contract:

And subscribe this consumer:

After publishing a ‘SubmitOrderV2’ message, our consumer is called as expected.

> New Order consumed

So far nothing special.

Consuming the backwards compatible version

The question is what happens when we send our ‘SubmitOrderCommand’ that implements both message contracts.

If we have only one consumer subscribed the behavior is completely the same as before and either the old or the new consumer is called.

But if we have both consumers subscribed:

Each one will get a copy of the message and be called:

> Old Order consumed
> New Order consumed

Ok, that is good to now. But what happens if one of the consumers now fail?

Althought the first consumer is called succesfully, the message will still end up on the error queue:

If we then move the message back to the original queue, both consumers will be called again.