Catch failed message when service is out-of-memory killed

[TobiasWolters]

In our system, we have a handler that handles specific commands, similar to the following:

public class JobHandler : IHandleMessages<ExecuteJob>, IHandleMessages<IFailed<ExecuteJob>> { ... }

We have set up second-level retries.

This setup works perfectly if the JobHandler fails to handle a job with a regular .NET exception - i.e. the HandleFailed method in JobHandler is called.
However, in some cases, the pod that runs the JobHandler is out-of-memory killed. If this happens too many times, we eventually get the following error:

Moving message with ID <GUID> to error queue <error-queue> - error details: "1 unhandled exceptions: <date>: Rebus.Exceptions.RebusApplicationException: Received message with native delivery count header value = 5 thus exceeding MAX number of delivery attempts (which is 4, i.e. 2 x 2 because 2nd level retries are enabled) – the error tracker did not provide additional information about the errors, which may/may not be because the errors happened on another Rebus instance."

As indicated in the error message, the ExecuteJob command is moved to the error queue, but the HandleFailed method in JobHandler is never called.

Is it possible to somehow catch and react to the failed ExecuteJob command in this case?

From looking at the code, it seems like it could be possible to implement IErrorHandler and register that custom error handler. However, we would like to still use the functionality of the default DeadletterQueueErrorHandler.

Any suggestions on how to approach this issue?

[TobiasWolters]

@mookid8000 Any ideas or suggestions related to this?