[dependabot]

Updated WolverineFx from 6.48.1 to 6.48.3.

Release notes

Sourced from WolverineFx's releases.

6.48.3

A patch release for blue/green warm-ups at fleet scale, from a second production report by @​erdtsieck on 6.48.2: every green-only agent went to the first green node to register, and the two green nodes that joined seconds later got nothing for half an hour.

• A warm-up spreads over every green node that joins (#​4904, @​erdtsieck). Four causes, all in the leader: the pending-start ledger was re-applied over the whole grid before every family's pass, so the passes after the event-subscription family put each still-queued agent back on the first green node and the decision to move it never left the leader; a move of a start that was still only queued waited in the source node's lane behind that node's whole backlog, and now goes straight to the new node; the group-affinity fallback had no per-node ceiling; and a move of an agent whose first move had not landed could start it on a third node, so an outstanding move is now left alone until it lands.
• Three gaps in that new machinery, found by a randomized soak on real dispatcher lanes (#​4909). A start queued for a node that had since left no longer steals the claim of a newer start elsewhere; a queued re-drive of a start whose assignment row has not surfaced yet is no longer withdrawn by a later move as if it had never run; and a pending move that goes unconfirmed past the ledger's TTL during a long start — the field's own shape, 27-second starts against a 20-second TTL — is re-driven as the stop-then-start it was, never as a bare start that skips the stop at a source whose copy is still coming up.
• Fleet-scale simulated scenarios (#​4905, @​erdtsieck). A full blue/green deploy, a green node dying mid-wave, the leader dying mid-warm-up, starts failing against some databases, slow starts on every node, and blue pods that captured different tenant sets, replayed through the simulated cluster with real dispatcher lanes; a production-sized shape (512 databases, ~100,000 agents) is opt-in with WOLVERINE_FLEET_SCALE=production.
• A chain that only reads through IQuerySession but sends messages now gets its commit (#​4910, @​srimalw; #​4912 for Polecat and Fisher). The IQuerySession permutation of #​2941: the read-only parameter was served by casting the outbox-enrolled session, but CanApply ignored it, so a scheduled cascade was never handled and a durable local message only ever ran from memory. Reading alone still does not make a chain transactional; reading plus sending does — an injected IMessageBus, a returned OutgoingMessages, or a cascading return value.

Everything else is as in 6.48.2.

6.48.2

A patch release for agent assignment at fleet scale, from a production report by @​erdtsieck: ~62,000 per-tenant event-subscription agents on 5 to 8 nodes, where a newly elected leader spent 66 minutes in its first assignment evaluation during a blue/green warm-up and three leaders in a row were replaced before one finished.

• Matching agents to capable nodes goes through a hash set instead of a list scan (#​4886, @​erdtsieck). AssignmentGrid.MatchAgentsToCapableNodesFor was quadratic in the agent count whenever any capability differed between nodes — which a single bumped projection version is enough to trigger.
• The rest of that first evaluation is no longer quadratic either (#​4893). Four more scans of the same shape on the same path: batchCommands removing each start command from the list one at a time, the heartbeat Fill()-ing every running agent into the node record, per-placement Fill() on the grid's node, and per-placement recounts in both even distribution paths. Measured through the leader's real evaluation at the reported shape: the even blue/green path's first evaluation went from 76 s to under 5 s.
• A newly elected leader holds unplaced agents for one evaluation after a takeover (#​4899). The pending-assignment ledger is leader-local, so a leader replacing one that died with starts in flight could not see them and could start an agent a second time on another node. New DurabilitySettings.LeaderTakeoverHoldEvaluations (default 1, 0 disables) withholds bare first-time placements for that many evaluations after election, so the predecessor's starts can surface as assignment rows and be kept where they are. It stands down when no other node holds any assignment, so a cold start pays nothing.
• Lifecycle and soak coverage for assignment (#​4893, #​4896). A simulated cluster drives the leader's real evaluation through whole lifecycles — a full blue/green deploy, a leader replaced or killed mid-wave, scale-down, repeated scale-up/down — asserting no double start, no cross-fleet placement and bounded convergence at every step, plus an opt-in randomized soak (WOLVERINE_CHAOS_SOAK=<rounds>) that stays out of CI.

Everything else is as in 6.48.1.

Commits viewable in compare view.

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 commands and options

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)