Enlist Lightweight-mode HTTP storage-action chains in the EF Core outbox (GH-3353)

[jeremydmiller]

Closes #3353. Follow-up to #3291 / #3298.

The bug

The #3291 fix landed in EFCorePersistenceFrameProvider.ApplyTransactionSupport(chain, container) — the two-argument overload reached from AutoApplyTransactions. The entityType overload — reached from the storage-action side-effect return types (IStorageAction<T>, Storage.Insert/Store/Update/Delete) — had no such branch. The two are mutually exclusive via the UsingEfCoreTransaction chain tag, and AutoApplyTransactions only claims chains with a DbContext service dependency, so a Wolverine.Http endpoint that persists purely through a storage action (never injecting the DbContext) was claimed only by the unfixed overload. In Lightweight mode its cascaded messages were dispatched by the send-now branch of MessageBus.PersistOrSendAsync before SaveChangesAsync commits.

The fix

Mirror the #3291 branch into the entityType overload — reusing the exact same proven frames (EnlistDbContextInOutbox middleware + CommitEfCoreEnvelopeTransaction postprocessor) — with one deliberate difference: no chain.RequiresOutbox() gate. As the issue analysis predicted, that gate is unsatisfiable there: the overload runs from SideEffectPolicy (registered ahead of OutgoingMessagesPolicy in the WolverineOptions constructor), and HttpChain.RequiresOutbox() only reflects an injected IMessageBus/MessageContext — which the storage-action endpoint shape never has. Enlisting an endpoint that turns out not to cascade anything is a no-op flush at commit time.

While hardening this, both HTTP branches (the new one and the shipped #3291 one) now also require database-backed message persistence, mirroring the EfCoreEnvelopeTransaction constructor's precondition (TryFindMessageDatabase). Without that guard, a persistence-less EF Core application (plain AddDbContext, no message store) would generate code that throws InvalidOperationException on every request; it now keeps its pre-existing send-now composition. A dedicated test covers this.

Message handlers and Eager mode are untouched; multi-tenant EF Core chains are excluded exactly as in #3291.

The reproducer

Per the issue, the bug needs an application that uses EF Core but not Marten. The main Wolverine.Http.Tests assembly can't host that (its endpoints assume Marten at chain-construction time — [Entity]-loaded Marten documents fail EntityAttribute.Modify without it), so this PR adds a tiny Wolverine.Http.Tests.EfCoreOnly assembly holding just the endpoint + DbContext, and the test pins opts.ApplicationAssembly there (the established generate_openapi_without_database pattern). With no Marten registered, EF Core is naturally the only persistence frame provider — no provider-ordering games needed.

Bug_3353_lightweight_storage_action_cascade asserts at the codegen surface, matching the sibling #3291 reproducers: EnlistInOutboxAsync present, no standalone FlushOutgoingMessages postprocessor, and enlist → SaveChangesAsync → CommitAsync ordering. Red on main at the EnlistInOutboxAsync assertion; green with the fix.

Verification

• Both new tests green; full Wolverine.Http.Tests: 812 passed / 0 failed (net9.0).
• EfCoreTests: 186/187 — the one failure is Bug_1846_duplicate_execution_of_scheduled_jobs, which passes in isolation (load-flaky locally).
• EfCoreTests.MultiTenancy: 135/141 in full-suite local runs, but the identical 6 SqlServer failures reproduce on unmodified main in a clean worktree against the same containers, and all 52 SqlServer MT tests pass in isolation on this branch — pre-existing local full-suite interference, not this change. (The MT suite's own with_http_posts_using_storage_actions — HTTP storage actions over multi-tenant EF Core — passes everywhere.)
• Full wolverine.slnx Release build: 0 warnings, 0 errors.

🤖 Generated with Claude Code