Scoped Filters execute after topology conventions are applied when publishing/sending

[flannoo]

Contact Details

[email protected]

Version

8.x

On which operating system(s) are you experiencing the issue?

Linux

Using which broker(s) did you encounter the issue?

RabbitMQ

What are the steps required to reproduce the issue?

Setup an application that publishes messages to a RabbitMq topic and a consumer that reads messages from that topic.

In v8.2.0 it works fine but starting v8.2.1, the consumer is no longer picking up messages (the publish seems to work fine).

I created a github repo with a .NET application that reproduces this issue.

The app is configured with v8.2.0 which works without problems.
If you update the MassTransit packages to v8.2.1 or 8.2.2, then the consumer no longer works.

What is the expected behavior?

I'd expect the MassTransit package to have the same behavior as v8.2.0 in the later patch releases, since it shouldn't introduce breaking changes in a patch version.

What actually happened?

Bumping our MassTransit packages to the latest patch version broke our consumers

Related log output, including any exceptions

No response

Link to repository that demonstrates/reproduces the issue

https://github.com/flannoo/masstransit-consumer-issue

[phatboyg]

It isn't working now because the RoutingKeyFormatter is executing before your scoped filter. The routing key formatter runs first because it is specified at a lower type level than the message type for the scoped filter, at least that's my suspicion. Previously it was a race condition based upon recursively resolving a message's parent types.

[phatboyg]

Why you wouldn't just do the work in the routing key formatter instead:

  configurator.Send<TEvent>(x =>
        {
            x.UseRoutingKeyFormatter(context =>
            {
                var durableEventName = (context.Message.GetType().GetProperty(DurableEventNameProperty)?.GetValue(context.Message))
                                       ?? throw new InvalidOperationException($"Message does not have the required property: {DurableEventNameProperty}" +
                                                                              $" Make sure to implement {nameof(IDurableEventName)}");

                return (string)durableEventName;
            });
        });

[flannoo]

I see, moving the work in the routing key formatter indeed fixes it in my repro case. I'll make the needed changes into our applications next week and will run regression tests, will keep you informed.

Thanks for the help!