Bump WolverineFx and WolverineFx.FluentValidation

[dependabot]

Updated WolverineFx from 6.23.0 to 6.23.1.

Release notes

Sourced from WolverineFx's releases.

6.23.1

Agent distribution

TL;DR: if you pause a projection from CritterWatch on 6.23.0, restarting it appears to do nothing for a full minute. This fixes that.

• A paused projection or subscription agent now resumes immediately when you restart it (#​3663). On 6.23.0 the restart was accepted, the pause restriction was cleared, and then nothing happened until the pending-assignment ledger's TTL expired — 2 × CheckAssignmentPeriod, so 60 seconds with the defaults. Long enough that an operator reasonably concludes the agent is never coming back.

  The ledger introduced in 6.23.0 (#​3622) only counted an assignment as confirmed if a later evaluation saw the agent running and still assigned to the same node. A pause makes those two conditions mutually exclusive: the first evaluation that can observe the delivered assignment is the same one that detaches the agent. The entry was never confirmed, nothing on the stop path cleared it, and the restart's AssignAgent was suppressed as a duplicate still in flight. Delivery alone now confirms the entry, which is the only question the ledger was ever asking.

• Pausing an agent no longer briefly starts it first (#​3666). ApplyRestrictionsAsync kickstarted a health check before persisting the operator's restriction change, so that evaluation ran against the old restrictions and could act against the very intent being applied — for a pause, re-assigning and starting the agent one beat before the merged evaluation stopped it again. Besides the wasted daemon start/stop cycle, this is what armed the stale ledger entry behind #​3663.

PostgreSQL

• Advisory-lock sessions stay invisible to Marten's async-daemon gap detection (#​3664). Marten 9.16.1+ will not skip a stale event-sequence gap while any session whose open transaction predates that gap is still alive (marten#​4953). A session parked in an open transaction for the life of the process therefore reads as a permanent "possible reserver" and can hold the high-water mark — and every async projection — behind a gap that is genuinely dead.

  Wolverine's long-held locks were already shaped correctly: leader election and node coordination hold session-scoped advisory locks on a dedicated connection with no transaction, so they show up as state='idle' with a NULL xact_start. Those sessions are now also tagged application_name = 'wolverine-advisory-lock:<database>', which turns a pg_stat_activity investigation from guesswork into something you can read at a glance. The constraints are pinned in tests and in the Postgres durability docs, including the trap worth knowing in your own code: never add a keepalive query inside a long-lived open transaction — it bumps state_change, makes the session look active, and re-promotes it to candidate reserver.

  Note for combined Marten + Wolverine deployments: older guidance suggested Postgres's idle_in_transaction_session_timeout as a dead-gap backstop. Prefer upgrading Marten and using SkipStaleGapsDespiteLiveTransactionsAfter instead.

Commits viewable in compare view.

Updated WolverineFx.FluentValidation from 6.23.0 to 6.23.1.

Release notes

Sourced from WolverineFx.FluentValidation's releases.

6.23.1

Agent distribution

TL;DR: if you pause a projection from CritterWatch on 6.23.0, restarting it appears to do nothing for a full minute. This fixes that.

• A paused projection or subscription agent now resumes immediately when you restart it (#​3663). On 6.23.0 the restart was accepted, the pause restriction was cleared, and then nothing happened until the pending-assignment ledger's TTL expired — 2 × CheckAssignmentPeriod, so 60 seconds with the defaults. Long enough that an operator reasonably concludes the agent is never coming back.

  The ledger introduced in 6.23.0 (#​3622) only counted an assignment as confirmed if a later evaluation saw the agent running and still assigned to the same node. A pause makes those two conditions mutually exclusive: the first evaluation that can observe the delivered assignment is the same one that detaches the agent. The entry was never confirmed, nothing on the stop path cleared it, and the restart's AssignAgent was suppressed as a duplicate still in flight. Delivery alone now confirms the entry, which is the only question the ledger was ever asking.

• Pausing an agent no longer briefly starts it first (#​3666). ApplyRestrictionsAsync kickstarted a health check before persisting the operator's restriction change, so that evaluation ran against the old restrictions and could act against the very intent being applied — for a pause, re-assigning and starting the agent one beat before the merged evaluation stopped it again. Besides the wasted daemon start/stop cycle, this is what armed the stale ledger entry behind #​3663.

PostgreSQL

• Advisory-lock sessions stay invisible to Marten's async-daemon gap detection (#​3664). Marten 9.16.1+ will not skip a stale event-sequence gap while any session whose open transaction predates that gap is still alive (marten#​4953). A session parked in an open transaction for the life of the process therefore reads as a permanent "possible reserver" and can hold the high-water mark — and every async projection — behind a gap that is genuinely dead.

  Wolverine's long-held locks were already shaped correctly: leader election and node coordination hold session-scoped advisory locks on a dedicated connection with no transaction, so they show up as state='idle' with a NULL xact_start. Those sessions are now also tagged application_name = 'wolverine-advisory-lock:<database>', which turns a pg_stat_activity investigation from guesswork into something you can read at a glance. The constraints are pinned in tests and in the Postgres durability docs, including the trap worth knowing in your own code: never add a keepalive query inside a long-lived open transaction — it bumps state_change, makes the session look active, and re-promotes it to candidate reserver.

  Note for combined Marten + Wolverine deployments: older guidance suggested Postgres's idle_in_transaction_session_timeout as a dead-gap backstop. Prefer upgrading Marten and using SkipStaleGapsDespiteLiveTransactionsAfter instead.

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)

[dependabot]

Superseded by #113.