Bump WolverineFx from 6.28.2 to 6.29.2

[dependabot]

Updated WolverineFx from 6.28.2 to 6.29.2.

Release notes

Sourced from WolverineFx's releases.

6.29.2

A fix release. Four changes, three of them reported bugs.

RavenDB users should take this one

ClearAllAsync deleted node records by tracked entity from a session that had never loaded them, so a Solo-mode start after a Balanced-mode run threw InvalidOperationException: WolverineNode is not associated with the session on every stale node and the application could not start at all. The workaround of clearing WolverineNodes by hand in RavenDB Studio is no longer needed. (#​3993, closes #​3986)

The compliance coverage written for that fix caught a second provider: SQLite orphaned every agent assignment row, because its assignment table has no ON DELETE CASCADE (PostgreSQL, Sql Server and Oracle do). The orphans stay invisible until a node re-registers under the same id — the GH-3604 ejection path — where it returns owning agents it was never reassigned. The underlying gap was that NodePersistenceCompliance never exercised ClearAllAsync at all, which is how two providers shipped it broken. It does now.

Agents no longer stall on a node that cannot build them

When IAgentFamily.BuildAgentAsync threw, the leader saw only an unconfirmed agent — which it deliberately does not treat as a failure — so the assignment stood and the same agent was requested on the same failing node forever. Reported as a 54-minute fleet-wide projection stall on a blue/green cluster with disjoint projection versions. Consecutive failed starts are now counted on the node that catches them and feed into the existing GH-3888 release path. New DurabilitySettings.MaxAgentStartFailuresBeforeRelease (default 3); set it to 0 for the previous behaviour. (#​3994, closes #​3970)

The orphaned-message sweep no longer dominates database load

Reported against a 466-shard PostgreSQL deployment. The sweep's predicate could not use an index, so it full-scanned the whole inbox per database every five seconds to find nothing; the update was unbounded, so one node loss became a single ~910,000-row rewrite across the fleet; and it ran inside the shared recovery transaction, blocking inbox inserts. All three are fixed, with a new OrphanedMessageReleaseBatchSize and a dedicated OrphanedMessageSweepPollingTime. (#​3995, closes #​3971)

Upgrade note. This ships a partial index on owner_id, so PostgreSQL and Sql Server users will see one index applied on the next schema migration.

HTTP endpoints can take immutable request types

A Before / BeforeAsync method on an endpoint class that accepts the request type and returns it now replaces the request body for the rest of the chain, exactly as it has on the handler side since GH-516. Use it to stamp server-supplied values onto an immutable record request before the endpoint runs. (#​3984)

---

Full detail for every item is in CHANGELOG.md.

What's Changed

• GH-3983: MySQL migration idempotency, Weasel 9.25.1, and a green CIFisher by @​jeremydmiller in GH-3983: MySQL migration idempotency, Weasel 9.25.1, and a green CIFisher JasperFx/wolverine#3991
• Upgrade to Polecat 5.19.1 (and JasperFx 2.53.0) by @​jeremydmiller in Upgrade to Polecat 5.19.1 (and JasperFx 2.53.0) JasperFx/wolverine#3992
• GH-516 parity for HTTP: Before middleware can replace an immutable request body by @​danniewalden in GH-516 parity for HTTP: Before middleware can replace an immutable request body JasperFx/wolverine#3984
• GH-3986: ClearAllAsync must delete node records another process wrote (RavenDb + SQLite) by @​jeremydmiller in GH-3986: ClearAllAsync must delete node records another process wrote (RavenDb + SQLite) JasperFx/wolverine#3993
• GH-3970: release an agent this node cannot build or start to a capable peer by @​jeremydmiller in GH-3970: release an agent this node cannot build or start to a capable peer JasperFx/wolverine#3994
• GH-3971: make the orphaned-message sweep indexable, bounded, and self-contained by @​jeremydmiller in GH-3971: make the orphaned-message sweep indexable, bounded, and self-contained JasperFx/wolverine#3995
• Bump to 6.29.2 and add the CHANGELOG entries for the release by @​jeremydmiller in Bump to 6.29.2 and add the CHANGELOG entries for the release JasperFx/wolverine#3996

New Contributors

• @​danniewalden made their first contribution in GH-516 parity for HTTP: Before middleware can replace an immutable request body JasperFx/wolverine#3984

Full Changelog: JasperFx/wolverine@V6.29.1...V6.29.2

6.29.1

This bumps the Fisher dependency to 1.0. We needed this for the CritterWatch 1.0 release.

What's Changed

• docs: fix shrug emoticon rendering in sagas tip by @​MeGaurav4 in docs: fix shrug emoticon rendering in sagas tip JasperFx/wolverine#3982

New Contributors

• @​MeGaurav4 made their first contribution in docs: fix shrug emoticon rendering in sagas tip JasperFx/wolverine#3982

Full Changelog: JasperFx/wolverine@V6.29.0...V6.29.1

6.29.0

A feature release. Three of the five items fix silent failure modes — work that acted on a write which could still roll back, a convention mirror that installed a relay over a real handler, and two concurrent writers to one entity — so the notes below say what the old behaviour looked like, not just what changed.

AfterCommit — run work after the transactional commit

After reads like a post-handler hook that runs at the end. It does not run after the commit (#​3976, closes #​3975).

The commit is itself a postprocessor contributed by the persistence provider, and After methods are inserted at the front of that list. So an After method observing a write is observing one that is not durable yet and may still roll back — and there was no supported way to ask for the other side of it, even though Wolverine uses that position itself for the outbox flush.

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);
}

Use the AfterCommit / AfterCommitAsync convention or [WolverineAfterCommit], on message handlers, sagas and HTTP endpoints. Parameters bind exactly as After already does.

The position is structural, not positional — frames go into a new IChain.PostCommitPostprocessors list concatenated after every postprocessor at frame-assembly time, rather than being appended from a policy sequenced after the persistence policy. Getting the position right by luck of policy ordering is precisely what breaks silently later.

Two behaviours worth knowing:

• They do not run when the commit throws. Frames are concatenated without a try/finally, so the exception unwinds straight past them. That is the point — the reason to want "after the commit" is usually that the side effect must not happen for a write that did not land.
• They run after the outbox flush as well, so a message cascaded from an after-commit method is not atomic with the write. Cascade from the handler if it has to be.

After's pre-commit position is unchanged and stays that way. Verified per provider: Marten, Polecat, Fisher, EF Core, RavenDb and CosmosDb each have a codegen test asserting the emitted call lands after that provider's own commit frame.

A store-agnostic EventsToAppend return type

Wolverine.Marten.Events, Wolverine.Polecat.Events and Wolverine.Fisher.Events are identical but store-named, so a handler that wanted to be store-agnostic could not name any of them (#​3969, closes #​3941).

The store-agnostic path did exist — a bare IEnumerable<object> return is picked up by a fallback — but that fallback is positional. IEnumerable<T> is covariant, so every reference-typed collection in a return tuple is a candidate and the first one wins. Nothing failed at codegen and nothing failed at runtime; the wrong collection simply became the appended events.

The type is EventsToAppend, not Events. Naming it Events would have been a source-breaking collision (CS0104) for any handler importing both the core event-sourcing namespace and a store integration — that is, on the very declaration the feature exists for.

Ask what will be handled, and how a batch is shaped

Discovery materializes after options time, so an extension installing fallback handlers could not ask "will this message type have a handler?" and had to hand-roll a mirror of Wolverine's own discovery convention (#​3977, closes #​3974).

Such a mirror drifts, and it drifts silently: one that scanned a single assembly stopped seeing handlers that moved to a second, and installed a bare relay over a real handler — the exact defect the guard existed to prevent, with every codegen test still passing.

opts.OnHandlersDiscovered(handlers =>
{
    if (!handlers.Handles<ServiceUpdates>())
    {
 ... (truncated)

Commits viewable in [compare view](http://github.com/jasperfx/wolverine/compare/V6.28.2...V6.29.2).
</details>

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=WolverineFx&package-manager=nuget&previous-version=6.28.2&new-version=6.29.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)


</details>