No, the reply just results in a message going back to the endpoint sending the message being replied to.
But is is the endpoint that originally sent the message, or is it the endpoint that sent the message to that particular service? What I mean is if the UI sends a message to service A which handles the original command, and A spawns a command to service B, and B spawns to C. If C replies, would that simply be replying to B but not A? If it were a Saga, then I see it would be the Saga that actually replied, but without a Saga, wouldn’t I have to modify the reply to address at every touch point?
Also, correct me if I’m wrong, but don’t replies require that I make the endpoints uniquely identifiable? I thought that was a requirement of the callbacks package. We discussed that one in a different thread (Callbacks uniquely identifiable endpoint concerns when deployed in docker - #26 by andreasohlund)
I don’t really want to commit to using that package with that behavior. I could use my Redis package in place of that, but that actually is a synchronous call. I might be able to modify or extend it to simply forward to an endpoint. I’ll need to churn on that one a bit.
I guess I had simply planned on just getting into the habit of always firing success and error events for all commands, but I kinda see what you’re getting at now. Do you think it is unreasonable or bad practice to always fire success/error events as a system requirement?
In the meanwhile, let’s go back to the receive pipeline thought that you had. How did you envision that working?