Flush EF Core outbox before writing the HTTP response (GH-2917)

[jeremydmiller]

Closes #2917.

Problem

With Wolverine.Http + EF Core's transactional outbox, a transactional endpoint that returns cascading messages would leave an IHost.TrackActivity().ExecuteAndWaitAsync(...) session empty (no Sent/MessageSucceeded records) unless the caller added an explicit WaitForMessageToBeReceivedAt condition.

Root cause (deterministic ordering, not a flaky race): EF Core's Eager transaction middleware EnrollDbContextInTransaction wraps the rest of the chain in try { … } and emits efCoreEnvelopeTransaction.CommitAsync() at the end of the try block. CommitAsync commits the DB transaction and then flushes the outbox (sends the cascading messages). But the response-writing postprocessor (WriteJsonAsync) is inside that try block, before CommitAsync. So the generated endpoint wrote the HTTP response → the Alba client received it and ExecuteAndWaitAsync saw no in-flight activity and returned → then the outbox was flushed. Tracking missed the send. (Marten is unaffected because it flushes via a SaveChanges session listener, before the response.)

Fix

Reorder so the transaction commit + outbox flush run before the response is written:

• EnrollDbContextInTransaction no longer emits CommitAsync() at the end of its wrap — it just begins the transaction and provides the try/catch rollback wrapper.

• A new CommitEfCoreEnvelopeTransaction postprocessor performs the commit + flush. EFCorePersistenceFrameProvider adds it right after SaveChanges, which is before the response writer Wolverine.Http appends during codegen. The generated try block now reads:

  try {
      handler;
      SaveChanges;
      commit + flush;     // CommitEfCoreEnvelopeTransaction (was at end of wrap)
      WriteResponse;       // now after commit + flush
  } catch { rollback; throw; }
  

This preserves existing guarantees:

• The flush still runs after the EF Core commit → does not reintroduce the flush-before-commit row-stranding bug (Bug_efcore_outbox_flush_before_commit stays green).
• A failed commit now rolls back and never writes a success response — strictly more correct than before (previously the client got 200 before the transaction committed). Rollback-after-commit is a no-op because EF Core clears CurrentTransaction on commit.

Scope: the non-multi-tenant Eager path (EnrollDbContextInTransaction). Lightweight mode (standalone FlushOutgoingMessages) and message-handler chains are unaffected. The multi-tenant StartDatabaseTransactionForDbContext path still has the old ordering — a follow-up commit will extend the same reordering there.

Validation

• New regression test issue_2917_trackactivity_transactional_outbox passes deterministically (no explicit wait condition).
• Bug_efcore_outbox_flush_before_commit still passes (no flush-before-commit regression).
• Full Wolverine.Http.Tests: 771 passed, 10 skipped, 0 failed (EF Core + Marten HTTP).
• EfCoreTests, EfCoreTests.MultiTenancy, PersistenceTests compile clean.

The SQL Server-backed EF Core message-handler suites couldn't be run locally (emulated SQL Server too slow) — relying on CI here. The change is functionally equivalent for handlers (no response writer, so the commit postprocessor remains the last frame).

🤖 Generated with Claude Code

[jeremydmiller]

Follow-up commit 66da0ce7 extends the same reordering rule to the multi-tenant EF Core path (StartDatabaseTransactionForDbContext), which had the same response-before-flush ordering plus a latent flush-before-commit (its raw CommitTransactionAsync ran at the end of the wrap, after the response writer, and the standalone FlushOutgoingMessages ran after the response and before that commit).

• StartDatabaseTransactionForDbContext no longer commits at the end of its wrap.
• New CommitTenantedDbContextTransaction postprocessor commits the DbContext transaction then flushes the MessageContext, added right after SaveChanges (before the response writer). It implements IFlushesMessages so the chain doesn't also add a standalone FlushOutgoingMessages (no double flush, no flush-before-commit).

Net generated order for multi-tenant chains is now handler; SaveChanges; commit; flush; WriteResponse — matching the single-DbContext path. Relying on the EfCoreTests.MultiTenancy CI suite to validate the multi-tenant runtime paths (tenant databases aren't easily provisioned locally).