Reading the documentation, it says:
- Due to possible failures, a given message may be sent multiple times. For example, if an exception is thrown in step 3 (failure to update outbox storage) the message will be read from outbox storage again and will be sent again. As long as the receiving endpoints use the outbox feature, these duplicates will be handled by the deduplication in phase 1, step 2.
I was wondering how exactly this deduplication phase works when the transport is rabbitmq and the outbox persistence is sql server. It is not possible to have a transaction between these two so once you have successfully handled your rabbitmq message, it seems to me the sql server call to update the outbox as 'message delivered to queue' can still fail, resulting in handling the rabbitmq message more than once on the receiving endpoint in case the sending endpoint sends again in the meantime?
I feels like I'm making a reasoning error because I don't fully understand how it works.
Any insights?
Yes, the SQL call to set Dispatched = true can still fail, and then the RabbitMQ message would be handled again. But the next time it's handled, before invoking the message handler it will
select from Outbox where MessageId = <id>and see that the message handler was already successfully invoked and the results committed to the database the last time around, and so it will skip over the message handler and go directly to the dispatch phase.So even if there was an odd problem with the SQL server where 100 duplicates got created because you couldn't set Dispatched on that table, the receiving endpoint running deduplication would receive all 100 messages but after the first one be going "Seen it, seen it, seen it, seen it…"