InvalidOperationException with message "An error occurred when attempting to complete the transaction context"

[michielvoo]

Implemented a very simple message handler, but getting an InvalidOperationException after the Handle method returns:

An error occurred when attempting to complete the transaction context
Tried to complete the transaction context, but SetResult has not been invoked!
at Rebus.Transport.TransactionContext.Complete()
at Rebus.Workers.ThreadPoolBased.ThreadPoolWorker.ProcessMessage(TransactionContext context, TransportMessage transportMessage)

(Source of this exception, introduced in the "fix some stuff" commit.)

public Task Handle(MyMessage message)
{
    _logger.LogInformation("Receive my message");

    return Task.CompletedTask;
}

The message is not completed in Azure Service Bus.

I have to call MessageContext.Current.TransactionContext.SetResult(true, true); to not get this exception and to complete the message. This is not in the Rebus examples, and some code I wrote about 2-3 years ago also did not require this. Was something changed?

We configure Rebus for Azure Service Bus like this:

configurer.Transport(t =>
{
    t.UseAzureServiceBus(azureServiceBusConnectionString, queue, tokenCredential);
    t.UseNativeDeadlettering();
}

How should I configure Rebus so that we don't need a call to MessageContext.Current.TransactionContext.SetResult in every handler?

[mookid8000]

That sounds very weird, because that's clearly supposed to work.

Could you check out this example and figure out how your code differs from it?

[michielvoo]

Thanks for the link! I ran that test locally and it works. You asked for the differences, and our code does contain some custom middleware. I must admit I do not have experience working with Rebus transactions. Would it still be possible that our middleware does something to trigger this check, despite not doing anything with TransactionContext or RebusTransactionScope?

Could you help me understand that by answering the following question:

When I set a breakpoint in TheMostInterestingHandlerInTheWorld.Handle() on the line where it returns (here), and inspect Rebus.Pipeline.MessageContext.Current.TransactionContext, I can see that both _mustAck and _mustCommit are null, which would cause execution to enter this block and throw an InvalidOperationException. Why does that not happen when I run the test you linked to?

If I know why TransactionContext.Complete() is not causing a problem in the test you linked to, but does cause a problem in our code base, then I can hopefully find the root cause.

Thanks!

[mookid8000]

Why does that not happen when I run the test you linked to?

Simply because _mustCommit gets set by Rebus after having executed a handler without an exception.

I suggest you try running your handler without any of your custom middlewares to begin with, and then you enable them, one by one, to see what could be the possible source of the error (here assuming, of course, that it runs without errors without the middlewares).

OTOH if you can reproduce the error without any of your own customizations when I would be happy to debug it.

[michielvoo]

Thanks again for your help @mookid8000.

The problem was that we removed DefaultRetryStep. Probably because we wanted to rely on Azure Service Bus for retries and dead-lettering (and use our logs to diagnose the root cause of dead-lettered messages, since we always log correlation ID and message ID). This was in the v6 timeframe, and back then removing the step did not cause any problems. But after updating to v8 removing the default retry step started causing problems, because that is the step that is responsible for calling SetResult() (here).

Solution: don't remove the default retry step, and instead learn how to take advantage of the retry mechanism it offers.

[mookid8000]

Excellent, good to hear you figured it out 🙂