Looking to get a best practice for this particular scenario here from the experts.
We’ve got a handler set up working in a dialog between an end user app (legacy MVC) and another backend system leveraging the nifty callbacks feature.The user clicks the button, message goes out, it processes, result information is returned to the replyTo queue, client code resumes the await, scenario continues in the controller. Easy peasy and life is good.
Let’s just call this particular code IFooCommand that has a corresponding IFooResponse message.
So the question’s come up about handler implementation that the caller may be expecting a reply and simultaneously supporting clients that don’t care (eventual is good enough). If the caller isn’t waiting for a reply the response message gets dumped in the error queue because there’s no one expecting the reply message and no handler’s in place.
Is there a clean way in a handler to know if Reply is expected or not by the caller to take the appropriate action?
Is it perhaps better to reveal the intention explicitly via two messages instead (IFooDialog/Response vs IFooCommand) and have the handler implement both? Flags? Other magic?
What’s the general consensus for this type of scenario?
For completeness we’re using
Sql Transport 3.0.0
Castle integration 6.0.0
NHibernate integration 7.1.1