Take advantage of NoMatchingSubscribers to avoid timeout when using InvokeAsync over MQTT 5

[varondel]

Hello,
We are trying to use wolverine's request/reply over an MQTT broker in a situation where we might have a listener or not for a given endpoint.
If there is a listener, we want to wait for its response. This case is working fine.
But if there is no listener to handle the message, wolverine is waiting for the reply until the timeout is triggered.

It seems that with MQTTNet there is now a possibility to know if there is a subscriber when a message is published :
https://github.com/dotnet/MQTTnet/blob/18731d9f02345a0fcec899ebfbd4bff7c05a57ce/Source/MQTTnet/Protocol/MqttPubAckReasonCode.cs

/// <summary> /// The message is accepted but there are no subscribers. This is sent only by the Server. If the Server knows that there are no matching subscribers, it MAY use this Reason Code instead of 0x00 (Success). /// </summary> NoMatchingSubscribers = 16,

Maybe it could be possible to take advantage of this return code and add the possibility to configure wolverine so that it does not endlessly wait for the response ? Or maybe this kind of feature would be to specific to MQTT and goes against wolverine spirit ?

Anyway we would be highly interested in a way to use the request/reply feature of wolverine with :

1. The possibility to have no replier for a given request.
2. Receive an instant "empty" reply instead of a timeout.

Best regard.

[jeremydmiller]

@varondel That's not something we support today, but the use case sounds reasonable. You might be in "I take pull requests" territory though