Allow to set mandatory=true when publising messages to RabbitMQ

[IlBaffo]

Is your feature request related to a problem? Please describe.
Messages published through a RabbitMQ Exchange can be lost without a trace when a valid routing is not present.

See: https://www.rabbitmq.com/docs/publishers#unroutable

While "fire-and-forget" semantics are ok in many cases, there are other cases (such as task queues) when publishing unroutable messages with SendAsync should result in an immediate exception.

Describe the solution you'd like
It should be possible to override the mandatory parameter that is passed to RabbitMQ when configuring the routing.

See: https://www.rabbitmq.com/client-libraries/dotnet-api-guide#basic-return

I don't know what granularity to provide here but, at least, it should be possible to set it per-message-type like:
wolv.PublishMessage<DoImportantThingCommand>().ToRabbitTopic("commands.important", "my-exchange", mandatory: true);

I did not look at the other transports implementations but it is probably not possible to generalize this setting at the envelope level because it is not applicable outside RabbitMQ.

Ideally SendAsync, as opposed to PublishAsync should always apply this behaviour in my opinion but, since it cannot be enforced outside RabbitMQ it is not possible.

Describe alternatives you've considered
I don't think there is any other alternative since only RabbitMQ can handle this.
Dead lettering can not work for unroutable messages.
An Alternate Exchange could be provided but this is kind of useless for two reasons:

• the Alternate Exchange has the same behaviour, so it can drop messages if no queue is attached to it either...
• who will consume the Alternate Exchange's queue?

Additional context
This is more likely to happen with Topic exchanges, when destination queues are dynamic by nature and the producer cannot create and bind the queues beforehand.

Thanks.

[jeremydmiller]

@IlBaffo Sounds helpful to some, but this is 100% an "I take pull requests" issue. Might not be as helpful as you think though, because in many cases the publishing happens asynchronously. Might be easier though less to assert on exchanges having a binding at start up time.

[IlBaffo]

@IlBaffo Sounds helpful to some, but this is 100% an "I take pull requests" issue.

You can take pull requests but I cannot send unsolicited pull requests with random code that would be 90% wrong because I don't know both the codebase and the design direction of the library, so I ask to have some feedback on the proposal first 😊

@IlBaffo Might not be as helpful as you think though, because in many cases the publishing happens asynchronously.

If the message is sent sincronously it could be handled like any other message that does not have any subsciber attached (so throwing an exception) because it is infact the case, only that the subscriber is not known to Wolverine.

If the message is being sent in an asyncronous fashion then it could be either:

• sent to Wolverine's DeadLetterQueue (if enabled)
• stay in the persistent Outbox (if enabled) to be retried

Because the issue could be fixed if bindings are added manually by an operator or if another instance of Wolverine comes online and registers the listener's queue with the proper binding.

Since I don't know how the other transport publishing failures are handled (I can find documentation about the consumers but not about the producers) but I think that there should be already infrastructure in place to handle other similar cases. I have to read the code and/or simulate some failure to understand better.

Just like if an user does not have permissions to send messages in a queue or a message is too large? Or if there is an exception in Rabbit's client.

@IlBaffo Might be easier though less to assert on exchanges having a binding at start up time.

This is not possible because of different reasons:

• listening queues (and routing/bindings) may be configured by another instance of Wolverine, residing in a separate machine
• Rabbit's binding syntax should be parsed and interpreted by Wolverine, making it fragile in case Rabbit's decided to implement additional expressions (beside a.b.*.c or a.#)
• wolverine should check for the presence of bindings at regular intervals to prevent data loss in case the bindings are changed at runtime from outside
• listening queues may even not be handled by Wolverine and be consumed by different software

Thanks.

[jeremydmiller]

@IlBaffo Just understand that this is not going to be a very high priority unless someone else picks this up

[jeremydmiller]

Actually, sorry, this just isn't going to happen anytime soon. I'm converting this to a discussion.

[IlBaffo]

OK no prob, thanks anyway. Maybe somebody will at least find some usefulness in the feedback itself.