Unable to FailFast when in second level retries.

[dtabuenc]

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, the FailFastStep 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.

[mookid8000]

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.

[dtabuenc]

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.

[mookid8000]

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");

🙂

[dtabuenc]

Perfect! This was exactly what I was looking for... don't know how I missed it.

[mookid8000]

(....) don't know how I missed it.

well, it wasn't always there, so I can understand why you would miss it 😁