Infinite _error messages after one empty payload message (0 bytes) because of JSON deserialize

This is a bug report.

Can you also reproduce the problem with the lastest version?

Reproduced with MassTransit version 5.1.4

Environment

1. Operating system: Windows 10 Enterprise
2. Visual Studio version: Version 15.7.6
3. Dotnet version: .NET Framework 4.6.1
4. RabbitMq version: 3.7.7 Erlang 20.3.8.5

Steps to Reproduce

1. Have the default MassTransit configuration for RabbitMq. And PrefetchCount and UseConcurrencyLimit of the IRabbitMqReceiveEndpointConfigurator both on 1.
2. Register a consumer endpointConfiguration.Consumer<TConsumer>(); and create the necessary message interface and consumer class (with implementation).
3. Start the process (We use a Windows Service) and see that the exchanges and queues are created.
4. Go to the RabbitMq Management page, go to the created queue and click on “Publish message” without any headers, properties or payload.

Expected Behavior

I would expect an _error queue to be created with one message stating the error.

Actual Behavior

Without ever hitting a breakpoint in the consumer.Consume, the _error queue is spammed infinitely (about 2000 in 10 seconds) (“infinite anything is always bad” I once heard a wise man say) with the same message (see screenshot). The message in the original queue will remain Unacked untill the consumer process is stopped. After stopping the process the message will go back to Ready. Restarting the process leads to the same scenario.

I’m guessing MT can’t find its headers or envelope, and unleashes its rage and fury on the _error queue. An obvious solution would be to not post a payload with 0 bytes, but some of our code monkeys (me) sometimes accidentally hit the nice looking button.

MT-Fault-ExceptionType:	System.NullReferenceException
MT-Fault-Message:	Object reference not set to an instance of an object.
MT-Fault-StackTrace:	at MassTransit.Serialization.JsonConsumeContext..ctor(JsonSerializer deserializer, IObjectTypeDeserializer objectTypeDeserializer, ReceiveContext receiveContext, MessageEnvelope envelope) 
at MassTransit.Serialization.JsonMessageDeserializer.MassTransit.IMessageDeserializer.Deserialize(ReceiveContext receiveContext)

[phatboyg]

Yeah, you need to give MassTransit enough permissions to do the things it needs to do, otherwise, bad things can happen. Locking it down to specific exchanges, etc. can cause problems like you experienced.

I;m going to close this since it isn’t actually an issue with MT.

[JosBijlenga]

Initially I get the same expected behaviour you get with my own minimal repro repos. After comparing the permissions in the Rabbitmq management page I noticed the configure regexp was different. My user was missing the the permission MassTransit:ReceiveFault. It did have all the other required permissions.

I dived deeper in the logs and the following error was displayed for every error message that was created: RabbitMQ.Client.Exceptions.OperationInterruptedException: The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=403, text="ACCESS_REFUSED - access to exchange 'MassTransit:ReceiveFault' in vhost '/' refused for user '(myusername)'"

I added the permission to access MassTransit:ReceiveFault, and now the behaviour is expected: 1 error message in the queue.

I’m assuming the issue is caused by recursion somehow. I hope this helps. I could share my code repo but as it’s an issue caused by RabbitMq configuration, I doubt it’d be of much help. Thank you for your time.