fix(efcore): suppress duplicate FlushOutgoingMessages in Eager-mode HTTP chains

[jeremydmiller]

Summary

Fixes a code-generation bug in the EF Core transactional middleware reported via the sample at https://github.com/dmytro-pryvedeniuk/outbox.

For an HTTP endpoint that takes a DbContext and publishes a cascading message, the generated handler emitted messageContext.FlushOutgoingMessagesAsync() BEFORE efCoreEnvelopeTransaction.CommitAsync(...):

// Added by EF Core Transaction Middleware
var result_of_SaveChangesAsync = await _tasksContext.SaveChangesAsync(...);

// Have to flush outgoing messages just in case Marten did nothing because of #536
await messageContext.FlushOutgoingMessagesAsync().ConfigureAwait(false);  // <-- early flush

await efCoreEnvelopeTransaction.CommitAsync(...).ConfigureAwait(false);    // <-- this commits + re-flushes

Runtime sequence: SaveChangesAsync writes the wolverine_outgoing row inside the open EF Core transaction (uncommitted). The early flush sends the cascading envelope through the transport sender, which then asks IMessageOutbox.DeleteOutgoingAsync (running on a separate connection) to remove the row — but the INSERT is still uncommitted and invisible to that connection, so the DELETE no-ops. The EF Core commit then makes the INSERT visible and the row is left stranded for the durability agent to re-send (at-least-once instead of the exactly-once semantics the outbox is supposed to provide).

Cause: EFCorePersistenceFrameProvider.ApplyTransactionSupport adds the FlushOutgoingMessages postprocessor whenever chain.RequiresOutbox() && chain.ShouldFlushOutgoingMessages(). The second condition is true for HttpChain but false for HandlerChain, which is why the bug was HTTP-only. In Eager mode the chain ALSO has EnrollDbContextInTransaction wrapping the body in a try block ending with efCoreEnvelopeTransaction.CommitAsync(...), and CommitAsync already calls _messaging.FlushOutgoingMessagesAsync() AFTER the DB commit. So in Eager mode the postprocessor is both redundant and unsafe.

Fix: gate the postprocessor add on mode != TransactionMiddlewareMode.Eager. Lightweight mode keeps it (no EnrollDbContextInTransaction wrap, so the postprocessor is the only flush trigger after SaveChangesAsync).

Tests

• src/Http/Wolverine.Http.Tests/Bug_efcore_outbox_flush_before_commit.cs — failing-then-passing test that asserts the /ef/publish HttpChain has zero FlushOutgoingMessages postprocessors. Inspects the postprocessor collection directly so the assertion works in both Dynamic and Static codegen modes. Confirmed to fail on main and pass after the fix.

• src/Persistence/EfCoreTests/Bug_efcore_outbox_flush_before_commit.cs — parameterised over TransactionMiddlewareMode.{Eager, Lightweight}, runs:

  1. Codegen check — handler chain never gets a FlushOutgoingMessages postprocessor in either mode (today protected by HandlerChain.ShouldFlushOutgoingMessages=false; locked down so a future change there can't silently introduce a double flush).
  2. Round-trip cleanup invariant — handler with [AutoApplyTransactions] publishes a cascading message to a UseDurableLocalQueues destination, and after TrackActivity completes the wolverine_outgoing_envelopes table is empty. Fills the gap that none of the existing EFCoreTests verified end-to-end outbox-row deletion after a durable send under the EF Core transactional middleware.

Test plan

• CI: .NET workflow green
• CI: efcore workflow green
• CI: http workflow green
• Local: 4/4 EFCoreTests Bug_efcore_outbox_flush_before_commit pass (2 codegen × 2 modes, 2 cleanup × 2 modes)
• Local: 6/6 Wolverine.Http.Tests/using_efcore.cs + Bug_efcore_outbox_flush_before_commit pass

🤖 Generated with Claude Code