Regression in 5.2: DB altering sql statements together with outbox writes don't persist anymore

[saithis]

Describe the bug
We have multiple endpoints that do things like that:

• efcore entity gets removed/updated/created and it also creates an event that it holds on to but doesn't publish yet.
• dbContext.SaveChanbgesAsync is called
• EfCore interceptor SavingChangesAsync collects the created event and calls dbContextOutbox.PublishAsync
• EfCore interceptor SavedChangesAsync calls dbContextOutbox.FlushOutgoingMessagesAsync

Since everything is contained in a single SaveChangesAsync call, we don't put a transaction around it.

With wolverine 5.1 this worked.
With wolverine 5.2+ the endpoints return success and we don't get exceptions, but the DB operation didn't persist.

This happens on both SQL Server and PostgreSQL.

Expected behavior
The DB operations should persist like they did with wolverine 5.1

Additional context
Executed SQL Queries with wolverine 5.1 and PostgreSQL:

DELETE FROM apikey."ApiKey"
WHERE "Id" = @p0;
INSERT INTO wolverine.wolverine_outgoing_envelopes (id, body, deliver_by, destination, message_type, owner_id)
VALUES (@p1, @p2, @p3, @p4, @p5, @p6)
RETURNING attempts;

delete from wolverine.wolverine_outgoing_envelopes where id = @id

Executed SQL queries with wolverine 5.2+ and PostgreSQL:

SAVEPOINT "__EFSavePoint";

DELETE FROM apikey."ApiKey"
WHERE "Id" = @p0;
INSERT INTO wolverine.wolverine_outgoing_envelopes (id, body, deliver_by, destination, message_type, owner_id)
VALUES (@p1, @p2, @p3, @p4, @p5, @p6)
RETURNING attempts;

RELEASE SAVEPOINT "__EFSavePoint";

delete from wolverine.wolverine_outgoing_envelopes where id = @id

I think this PR might be the one that introduced this regression: #1831
And I guess the problem is, that wolverine executes SAVEPOINT without there being a transaction around it.

[jeremydmiller]

@saithis You're even more in "I take pull requests" territory here. You're using the integration in a tiny bit of a non-idiomatic way. And yes, the EF Core integration changed to always use a transaction like that.

And regardless, I'd need more in the way of reproduction steps to make this actionable. "Make it work like it did before" isn't terribly helpful. I'd need to see your EF core interceptors or base class or whatever you did to customize this.

Happy to have a PR that opts out of the database transactions for EF Core middleware

And again, reach out anytime to sales@jasperfx.net to pursue a support contract and that will put this and the other issue (which might be a little more intractable or at least require much more conversation) much higher in our priority queue.

[saithis]

@jeremydmiller I'll see what I can do in therms of reproduction sample and/or PR.

I also noticed that when EnableRetryOnFailure() is enabled on the DbContext it fails with version 5.2+ now because wolverine created transactions directly instead of using CreateExecutionStrategy. In version 5.1 it still worked.

System.InvalidOperationException: The configured execution strategy 'NpgsqlRetryingExecutionStrategy' does not support user-initiated transactions. Use the execution strategy returned by 'DbContext.Database.CreateExecutionStrategy()' to execute all the operations in the transaction as a retriable unit.

(and I'm a bit confused, that on the one hand efcore complains that wolverine did create a transaction and on the other hand there is no transaction around the SAFEPOINTs)

[saithis]

This reproduces both issues mentioned here: https://github.com/saithis/wolverine-issue-2063

[jeremydmiller]

@saithis You've got a very non idiomatic approach. Wolverine has a built in model now for forwarding domain events from EF Core to Wolverine you can use:

https://wolverinefx.net/guide/durability/efcore/domain-events.html

I'm happy to take a pull request to allow for Wolverine to be used in your special approach here, but since we already have a built in recipe for that, I'm not willing to create a completely separate alternative. Sorry, but I'm closing this one.

[saithis]

@jeremydmiller Oh wow, I didn't even know this was added to wolverine, I must have missed that in the changelogs. I will adjust our services to this, then I can even throw away all the plumbing code that we wrote :)

Thanks!

[jeremydmiller]

I'm still happy to take a PR to have some alternatives to the EF Core transactional middleware though if you were interested in that. Or any extensions/change to the newer domain events stuff of course.