No handler found for message type...
See original GitHub issueI’m attempting to route messages from a producer to many consumers based on topics. I was attempting to have each consumer register with a subscription id specific to them and have all messages bound to just one queue per consumer. This works the first time I send a message, but the next time I send one – even if it is the exact same message payload – it fails with the following error…
No handler found for message type "<removed>"
The exception logged…
Exception thrown by subscription callback.
Exchange: '<removed>'
Routing Key: '<removed>'
Redelivered: '<removed>'
Message: <removed>
BasicProperties: <removed>
Exception:
System.AggregateException: One or more errors occurred. ---> EasyNetQ.EasyNetQException: No handler found for message type <remove>
at EasyNetQ.Consumer.HandlerCollection.GetHandler(Type messageType)
at EasyNetQ.RabbitAdvancedBus.<>c__DisplayClass14.<Consume>b__13(Byte[] body, MessageProperties properties, MessageReceivedInfo messageReceivedInfo)
at EasyNetQ.RabbitAdvancedBus.<>c__DisplayClass25.<Consume>b__24(Byte[] body, MessageProperties properties, MessageReceivedInfo receviedInfo)
at EasyNetQ.Consumer.HandlerRunner.InvokeUserMessageHandler(ConsumerExecutionContext context)
--- End of inner exception stack trace ---
---> (Inner Exception #0) EasyNetQ.EasyNetQException: No handler found for message type OrganizationAdded
at EasyNetQ.Consumer.HandlerCollection.GetHandler(Type messageType)
at EasyNetQ.RabbitAdvancedBus.<>c__DisplayClass14.<Consume>b__13(Byte[] body, MessageProperties properties, MessageReceivedInfo messageReceivedInfo)
at EasyNetQ.RabbitAdvancedBus.<>c__DisplayClass25.<Consume>b__24(Byte[] body, MessageProperties properties, MessageReceivedInfo receviedInfo)
at EasyNetQ.Consumer.HandlerRunner.InvokeUserMessageHandler(ConsumerExecutionContext context)<---
After much trial and error, it seems the issue comes into play when I set the Queue attribute on the messages I’m sending.
[Queue("someQ", ExchangeName="anExchange")]
public class SomethingHappened
{
DateTimeOffset When { get; set; }
string What { get; set; }
}
Once I remove the attribute and let EasyNetQ name the queues however it wants, it works fine.
Issue Analytics
- State:
- Created 8 years ago
- Comments:19 (8 by maintainers)
Top Results From Across the Web
No handler was found for message type 'Microsoft.M...
I see a popup with a totally useless error message as "No handler was found for message type 'Microsoft.Mashup.Evaluator.
Read more >No handler for message type websocket.group_send, how ...
After digging into the code, I found that I have 2 different consumers that connect to the same group. class MySecondConsumer( ...
Read more >What does "No message handler for this message" error ...
Translated into English that error actually means: The ECC Queue output record for a MID Server job specifies a bad value for the...
Read more >No handler for message type"? in Channels? : r/django
I've tried writing the type as "send_question" too, but that produces the same error.
Read more >No handler found found for Message (publish / subscribe)
This message is a No Handler Found for Message type error. ... I do not see any topics in the publishing not subscribing....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@StanislavChankov having multiple message types per queue is not supported by default, I have used it before by registering the HandlerCollectionPerQueueFactory as IHandlerCollectionFactory, if that doesn’t work anymore I don’t know.
@micdenny I think I may be able to shed some light on this. I had the problem of, while I was publishing/consuming via the autosubscriber just fine by using my custom names, each message still went to the default error queue with the above message.
The issue shows up when using the Autosubscriber and declaring your own queues via the attributes without declaring a topic. This is because without a topic, the queue is created automatically with # routing key.
However, if you decorate [ForTopic(“TOPIC”)] above your consume method… which means you HAVE to use bus.Publish(message, “TOPIC”), the error goes away.
Perhaps there should be a mention near the Attribute naming area of this.