-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HandleRetryAsync: Watch out when working with ExchangeBindings #314
Comments
Hi - thanks for reporting this. I'm trying to follow your diagram: are exchange B, C and D bound to exchange A (using exchange to exchange bindings)? How did the message end up on Exchange D (is A a topic exchange so that the message is routed to all services?) I think if the message is only delivered to D and you do a retry it is't wrong that it is re-published to A. |
Hi
Yes, its an exchange to exchange binding and all exchanges receive the message.
|
I've been thinking about this scenario and it makes sense. I've updated the middleware so that it tries to use the Thanks for reporting this! |
With a fallback to the exchange on which the message was published if the consumer configuration is not correctly extracted. This update makes it possible to have complex exchange to exchange bindings and still use the Retry enricher
Closing this for now, as it will be part of the upcoming release. Feel free to reopen this if the problem is still present in |
The retry queue is configured with
... {QueueArgument.DeadLetterExchange, deliveryArgs.Exchange}
Now assume you have an infrastructure as follows:
If a message was sent to Exchange A and processing fails in a component subscribing the queue bound to Exchange D then the message gets enqueue in the retry queue but with DeadLetterExchange = Exchange A! (this is where the message came from!)
So after TTL exceeds the message is rerouted to Exchange A and all other exchanges will get this message again!
The exchangename for the DeadLetterExchange has to be the exchange the subscriber bound it's queue to.
The text was updated successfully, but these errors were encountered: