GH-3975: add a declarative way to run work AFTER the transactional commit

[jeremydmiller]

Closes #3975.

After reads like a post-handler hook that runs at the end. It does not run after the commit. The commit is itself a postprocessor — each provider's ApplyTransactionSupport appends one — and After methods are inserted at the front of that list, so they run before the write is durable. There was no supported way to express the other side of it, even though Wolverine uses that position itself for FlushOutgoingMessages.

What's added

AfterCommit / AfterCommitAsync as a conventional method name, and [WolverineAfterCommit] for methods named something else. Same parameter binding After already has; works on message handlers, sagas and HTTP endpoints.

public static class RaiseAlertHandler
{
    public static void Handle(RaiseAlert command, IDocumentSession session)
        => session.Events.Append(command.Id, new AlertRaised(command.Reason));

    // Only runs if the append above actually committed
    public static void AfterCommit(AlertLatch latch, RaiseAlert command)
        => latch.MarkRaised(command.Id);
}

The position is structural, not positional

This is the part that matters. Frames go into a new IChain.PostCommitPostprocessors list that is concatenated after every postprocessor at frame-assembly time — not appended to Postprocessors from a policy sequenced after the persistence policy.

That's the issue's actual complaint: an application that gets the position right by luck of policy ordering gets it wrong the moment that ordering changes, silently, with every test still green. A separate list can't drift that way.

After's pre-commit position is deliberately unchanged, and there's a compatibility guard per provider asserting it stays there. Plenty of post-handler work has nothing to do with durability.

Verified per provider, not once

Each of Marten, Polecat, Fisher, EF Core, RavenDb and CosmosDb gets a codegen test asserting the emitted AfterCommit call really does land after that provider's commit frame, plus the guard that After still lands before it. List membership alone would only prove the frame went into the right list; the guarantee is about where it ends up relative to a frame contributed from a completely different code path, and only the emitted source shows that.

These are pure codegen assertions, so none needs a live server — including RavenDb, whose DocumentStore.Initialize() doesn't open a connection.

One provider difference worth flagging: CosmosDb has no commit postprocessor at all. Its ApplyTransactionSupport puts a TransactionalFrame in the middleware (the outbox enlistment) and only FlushOutgoingMessages in the postprocessors. Its test asserts against the flush rather than a SaveChangesAsync it never emits.

Core behaviour pinned

• the frame lands in PostCommitPostprocessors and not in Postprocessors
• the attribute works without the conventional name
• observed call order is Handle → After → AfterCommit
• an after-commit method does not run when an earlier postprocessor throws — frames are concatenated without a try/finally, so the exception unwinds past them. The issue asked for this to be pinned so it stays true.

Docs

The issue's nice-to-have was that the After name "points the wrong way for anyone thinking about durability." docs/guide/handlers/middleware.md now shows the emitted order explicitly, with the two caveats: these don't run when the commit throws, and they run after the outbox flush, so a cascade from one isn't atomic with the write.

Verification

• CoreTests middleware area: 33/33; new after_commit_middleware 4/4
• Marten / Polecat / Fisher / EF Core / RavenDb / CosmosDb: 2/2 each
• Full wolverine.slnx builds clean pinned to net9.0

🤖 Generated with Claude Code

https://claude.ai/code/session_01JG8Un6iNeyXECKJk3jo5uC

[jeremydmiller]

Full CoreTests regression on this branch: 2410 passed, 2 skipped, 0 failed (2412 total).

Per-provider after-commit tests: Marten 2/2, Polecat 2/2, Fisher 2/2, EF Core 2/2, RavenDb 2/2, CosmosDb 2/2. Full wolverine.slnx builds clean pinned to net9.0.