While debugging my NServiceBus enabled application, I have certain messages that are reported in the console as “failed maximum number of times”.
When I attach a debugger to the handler, everything is working as I would expect. The handler throws no exceptions.
The handler does however create an SQLTransaction, and is intentionally rolling the transaction back as part of the handling for some message scenarios. It seems to be that it is the messages that are getting transactions rolled back are the ones that are being reported as failed.
Is there some relationship between SQLTransactions and NServiceBus that would cause NServiceBus to recognize that a rollback has occurred?
I know that sounds unlikely, but cant think of anything else that might cause the message fail at this stage?
My guess (without seeing the exception error message) is that your error comes from handling SQL transactions manually.
If you’re running NServiceBus with default settings, message handling occurs inside a .NET
TransactionScope, also known as an “ambient transaction”. It’s likely that your SQL transaction gets enlisted in the ambient transaction, and thus your manually rolling back the transaction will result in an error.The “idiomatic NServiceBus way” (at least of you’re ok with ambient transaction and DTC), is to let NServiceBus do all the transaction handling. Therefore, you should either let your handler A) do its work, or B) throw an exception.
In both cases, the ambient transaction will ensure that any enlisted transactions will be committed/rolled back, depending on A or B.