🐛 Issue: FailurePolicy invoked multiple times after retries exhausted

[gergelyurbancsik]

Description

I think I’ve found an unexpected behavior related to handler retries and failure policies.

We have a HandlerPolicy setup where, after all retries are exhausted, a new message should be sent.
This message is then handled by another handler, which updates the Publication status to failed (or blocked).

However, it seems that when the failure message is sent, the corresponding handler is invoked multiple times, instead of just once.

✅ Expected behavior

FailurePolicy should be executed:

only after all retries are exhausted

only once

❌ Actual behavior

The handler triggered by the failure message is invoked multiple times

In my test, it was called 6 times

🔍 Relevant code

public void Apply(
    IReadOnlyList<HandlerChain> chains,
    GenerationRules rules,
    IServiceContainer container
)
{
    var matchingChains = chains.Where(x =>
        x.MessageType.BaseType == typeof(MyRequest)
    );

    foreach (var chain in matchingChains)
    {
        chain
            .OnException(e =>
                e is not ValidationException
            )
            .RetryWithCooldown(
                1.Seconds(),
                2.Seconds(),
                4.Seconds(),
                8.Seconds(),
                16.Seconds()
            )
            .Then.Discard()
            .And<MyFailurePolicy>();
    }
}

🧪 Evidence

There is a test proving that the failure handler is invoked 6 times

[jeremydmiller]

@gergelyurbancsik I was getting lazy, and honestly didn't believe you anyway (sorry). Here' the AI report on this:

  Most likely explanations for the user seeing 6 invocations:

  1. Transport-level redelivery — If the underlying broker (RabbitMQ, SQS, etc.) has its own retry/redelivery mechanism, the message could be redelivered with Attempts reset to 0, causing the entire
  retry chain to run again each time. Each redelivery would fire MyFailurePolicy once, so N redeliveries = N invocations.
  2. The MyFailurePolicy publishes a message, and that message's handler is what's being called 6 times — If the failure policy sends a new message and that message type also matches the same
  HandlerPolicy (e.g., if it also extends MyRequest), it would go through the same retry chain and fail again, creating a cascade.
  3. Global-level error policies — If the same failure policy is also registered globally on WolverineOptions.Policies, it would compound with the chain-level policy.

  Recommended investigation: Ask the user to:
  - Log envelope.Attempts inside their MyFailurePolicy to see if the attempts counter is 6 every time or if it starts from 1 repeatedly
  - Verify their failure message type doesn't also match the x.MessageType.BaseType == typeof(MyRequest) filter in their HandlerPolicy
  - Check transport-level retry settings (prefetch, nack behavior, etc.)
  - ```

I assume there's a failing test in one of your branches? Is that linked to me in your Github repo? I'll try that. Suspecting it's something about your setup and not Wolverine per se.