ExceptionRejector about aggregates.net HOT 3 CLOSED

Oh yes absolutely - what this behavior does is send a reply to a client when the message fails for any reason.
This behavior on the domain project https://github.com/volak/Aggregates.NET/blob/master/src/Aggregates.NET.Domain/Internal/CommandAcceptor.cs
is watching for business exceptions specifically - and ignoring them after sending a reply.

ExceptionRejector's purpose is just to send that reply when a message fails completely, because clients sending commands are usually always waiting for Accepted or Rejected replies. In fact this behavior sends the third type - Error.

from aggregates.net.

Well, I would argue that if a message ends up in the error queue that does not mean it failed completely. Something (like ServicePulse) is watching that queue and the operations should retry it in a timely manner. If that happens and the retry succeeds, the command sender will get an accepted response after getting an error. That would be confusing I think because, as a command sender, you can't treat error as an ultimate response.

from aggregates.net.

True - I should probably make that configurable. Personally I don't run with servicepulse and the client receiving an Error response is treated like a HTTP 500 - retry yourself later.
I am going to use the error queue just for debugging failed messages

from aggregates.net.