Closed dtabuenc closed 4 years ago
I've fixed the pseudo ID problem in Rebus 6.3.1, which is on NuGet.org in a few minutes.
Thanks for the precise description of the issue! 👍
Regarding the different retry strategies, it's still up to the developer to implement something, possibly using await bus.Advanced.TransportMessage.Defer(...)
in combination with the rbs2-defer-count
header.
This is, in fact what, I was doing... I'm referring to the last retry where I no longer want to defer and want to just forward the message to an error queue. Where I'm running into a problem is that once I determine (from checking the header) that I don't want to retry anymore and just want to dead-letter the message, I haven't found a way to just dead-letter and skip all further retries.
Since Rebus 6.2.1, it's been possible to
await bus.Advanced.TransportMessage.Deadletter();
the message, possibly with some custom error details:
await bus.Advanced.TransportMessage.Deadletter(errorDetails: "whatever, man");
🙂
Perfect! This was exactly what I was looking for... don't know how I missed it.
(....) don't know how I missed it.
well, it wasn't always there, so I can understand why you would miss it 😁
The message ID used to track second level retries is a different pseudo-message id and not the actual message ID. Due to this, when throwing an
IFailFastException
from within a second-level message handler, theFailFastStep
is unable to mark the message as final on the error tracker because it uses the original message id rather than the second-level pseudo-id.It would be nice to either be able to use the fail-fast functionality, or set up a different amount of first and second level retries, for the common case where second level retry will just defer for a number of times and then forward to the error queue after a set number of defers. It does not make a lot of sense to retry 5 additional times in these cases.