Yes. As an example of where we are running into an issue, we have an event being published which is picked up by multiple handlers in a single domain (eg, OrderSent in a CustomerService endpoint). This requires multiple handlers as they need to update individual aggregates in the domain. Those handlers are in charge of appending new events to SSS, which then broadcast these events once all the handlers complete using Outbox. If one of the handlers throws an exception, Outbox rolls back the events being published across all the handlers, but SSS is unaware of the transaction and doesn’t roll back the insertions into the database, breaking the idempotency. So short answer, yes we are receiving an event with multiple handlers, appending events to SSS then publishing new events once that completes.
Maybe I misunderstood the docs - In the Outbox examples it mentions that it uses a single TransactionScope (however it is casting it to manually provided SqlTransaction). Is that not ambient TransactionScope, or am I just misunderstanding the docs?
That seems to be the roadblock I ran into. While SSS appears to lock this option out, I was hoping NServicebus might have had a way to work around that limitation. I guess I’m surprised others have not run into this.
Edit - I was reading through this thread and it seems that one way of resolving this is moving to an event publisher that reads from the SSS event store. That way instead of writing and publishing events in the same step (which Outbox covers half), we append the new events in SSS and then have a separate event publisher that reads that database and publishes the new events as they appear. If this direction makes sense, do you know of any articles/sample-code that might take a similar approach?