Bump Marten and Marten.AspNetCore

[dependabot]

Updated Marten from 9.20.2 to 9.21.0.

Release notes

Sourced from Marten's releases.

9.21.0

Highlights

A small, low-risk release: two bug fixes reported against 9.20.x, a LINQ ordering fix, a Newtonsoft serialization fix, and a new health-check overload for Wolverine-managed daemon distribution.

[!NOTE]
There is a change to the mt_quick_append_events PostgreSQL function in this release, and applying it is NOT mandatory or required.

You do not need to patch your database, schedule a migration, or coordinate a deployment window to take 9.21.0. The client-side half of the #​5062 fix ships in the assembly, so upgrading the NuGet package alone is sufficient — 9.21.0 is correct against the function version you already have deployed.

Under the default AutoCreate.CreateOrUpdate the function is simply refreshed the next time Marten ensures event storage exists (a CREATE OR REPLACE FUNCTION, no lock on your event data). If you run AutoCreate.None with db-patch / db-apply, your next patch will contain one extra CREATE OR REPLACE FUNCTION … mt_quick_append_events statement — apply it whenever it suits your normal cadence. See the migration guide for details.

Bug Fixes

mt_quick_append_events returned {NULL} for an empty event array (#​5062, #​5088)

array_length('{}', 1) is NULL in PostgreSQL rather than 0, so calling the bulk append function with no events returned a bigint[] whose single element was NULL. Npgsql could not read that into long[], and the resulting InvalidCastException was thrown from the batch's post-processing loop — where it displaced whatever exception had actually made the append fail. Callers were left with an unrelated, non-retryable error instead of the real one; for the reporter that dead-lettered Wolverine messages which would otherwise have been retried.

Fixed on three fronts:

• The function now COALESCEs the array length, so an empty append means what it says: zero events appended, final version unchanged.
• The append operation no longer reads the returned array when the batch carries no events — this is what makes the fix effective without any database change.
• The one code path in Marten that could reach the function with empty arrays (ProjectionUpdateBatch.WaitForCompletion, for an Append side effect that ended up with no events) no longer issues the call.

OrderBy against a dictionary indexer dropped the key (#​5063, #​5073)

OrderBy(x => x.SomeDictionary["key"]) generated SQL that ignored the indexer key, so the ordering was wrong (or arbitrary) rather than failing loudly.

Lazy LINQ sequences serialized as objects under Newtonsoft (#​5076, #​5080)

A document property holding a deferred-execution sequence (Select(...), Where(...) without a materializing call) was written by Newtonsoft as an iterator object rather than a JSON array, so it would not round-trip. These are now written as plain arrays.

IMessageBatch is called concurrently (#​5065, #​5085)

Not a behavior change, but a documentation fix worth flagging if you implement IMessageBatch yourself: the async daemon raises projection side effects from multiple threads at once (measured at up to 8 concurrent publishers across 10 threads for a single-stream projection catching up). The interface previously said nothing about this. An implementation that appends to an unsynchronized collection will silently drop messages — the same hazard, in a real outbox, that showed up here as a "flaky" test.

New

Provider-aware databaseFilter for the high-water health check (#​5061, #​5089)

AddMartenHighWaterHealthCheck's databaseFilter is captured at registration time, so it cannot resolve services — which makes it unable to express "the databases this node currently owns" when ownership is runtime state. That is precisely the case under Wolverine-managed daemon distribution, where agents are assigned per (database, tenant) and rebalanced over a node's lifetime.

There is now an overload whose filter receives the IServiceProvider and is re-evaluated on every probe:

Services.AddHealthChecks().AddMartenHighWaterHealthCheck(
    (services, database) => services.GetRequiredService<IWolverineRuntime>()
        .Agents.AllLocallyOwnedDatabaseIds()
        .Any(id => id.Name.EqualsIgnoreCase(database.Identifier)),
    staleThreshold: TimeSpan.FromSeconds(30),
    includeExternallyManaged: true);
 ... (truncated)

Commits viewable in [compare view](https://github.com/JasperFx/marten/compare/V9.20.2...V9.21.0).
</details>

Updated [Marten.AspNetCore](https://github.com/JasperFx/marten) from 9.20.2 to 9.21.0.

<details>
<summary>Release notes</summary>

_Sourced from [Marten.AspNetCore's releases](https://github.com/JasperFx/marten/releases)._

## 9.21.0

## Highlights

A small, low-risk release: two bug fixes reported against 9.20.x, a LINQ ordering fix, a Newtonsoft serialization fix, and a new health-check overload for Wolverine-managed daemon distribution.

> [!NOTE]
> **There is a change to the `mt_quick_append_events` PostgreSQL function in this release, and applying it is _NOT_ mandatory or required.**
>
> You do not need to patch your database, schedule a migration, or coordinate a deployment window to take 9.21.0. The client-side half of the #​5062 fix ships in the assembly, so upgrading the NuGet package alone is sufficient — 9.21.0 is correct against the function version you already have deployed.
>
> Under the default `AutoCreate.CreateOrUpdate` the function is simply refreshed the next time Marten ensures event storage exists (a `CREATE OR REPLACE FUNCTION`, no lock on your event data). If you run `AutoCreate.None` with `db-patch` / `db-apply`, your next patch will contain one extra `CREATE OR REPLACE FUNCTION … mt_quick_append_events` statement — apply it whenever it suits your normal cadence. See the [migration guide](https://martendb.io/migration-guide.html#key-changes-in-9-21-0) for details.

## Bug Fixes

### `mt_quick_append_events` returned `{NULL}` for an empty event array ([#​5062](https://github.com/JasperFx/marten/issues/5062), [#​5088](https://github.com/JasperFx/marten/pull/5088))

`array_length('{}', 1)` is `NULL` in PostgreSQL rather than `0`, so calling the bulk append function with no events returned a `bigint[]` whose single element was `NULL`. Npgsql could not read that into `long[]`, and the resulting `InvalidCastException` was thrown from the batch's post-processing loop — where it **displaced whatever exception had actually made the append fail**. Callers were left with an unrelated, non-retryable error instead of the real one; for the reporter that dead-lettered Wolverine messages which would otherwise have been retried.

Fixed on three fronts:

* The function now `COALESCE`s the array length, so an empty append means what it says: zero events appended, final version unchanged.
* The append operation no longer reads the returned array when the batch carries no events — this is what makes the fix effective without any database change.
* The one code path in Marten that could reach the function with empty arrays (`ProjectionUpdateBatch.WaitForCompletion`, for an `Append` side effect that ended up with no events) no longer issues the call.

### `OrderBy` against a dictionary indexer dropped the key ([#​5063](https://github.com/JasperFx/marten/issues/5063), [#​5073](https://github.com/JasperFx/marten/pull/5073))

`OrderBy(x => x.SomeDictionary["key"])` generated SQL that ignored the indexer key, so the ordering was wrong (or arbitrary) rather than failing loudly.

### Lazy LINQ sequences serialized as objects under Newtonsoft ([#​5076](https://github.com/JasperFx/marten/issues/5076), [#​5080](https://github.com/JasperFx/marten/pull/5080))

A document property holding a deferred-execution sequence (`Select(...)`, `Where(...)` without a materializing call) was written by Newtonsoft as an iterator *object* rather than a JSON array, so it would not round-trip. These are now written as plain arrays.

### `IMessageBatch` is called concurrently ([#​5065](https://github.com/JasperFx/marten/issues/5065), [#​5085](https://github.com/JasperFx/marten/pull/5085))

Not a behavior change, but a documentation fix worth flagging if you implement `IMessageBatch` yourself: the async daemon raises projection side effects from **multiple threads at once** (measured at up to 8 concurrent publishers across 10 threads for a single-stream projection catching up). The interface previously said nothing about this. An implementation that appends to an unsynchronized collection will silently drop messages — the same hazard, in a real outbox, that showed up here as a "flaky" test.

## New

### Provider-aware `databaseFilter` for the high-water health check ([#​5061](https://github.com/JasperFx/marten/issues/5061), [#​5089](https://github.com/JasperFx/marten/pull/5089))

`AddMartenHighWaterHealthCheck`'s `databaseFilter` is captured at registration time, so it cannot resolve services — which makes it unable to express "the databases this node currently owns" when ownership is runtime state. That is precisely the case under Wolverine-managed daemon distribution, where agents are assigned per (database, tenant) and rebalanced over a node's lifetime.

There is now an overload whose filter receives the `IServiceProvider` and is re-evaluated on **every probe**:

```csharp
Services.AddHealthChecks().AddMartenHighWaterHealthCheck(
    (services, database) => services.GetRequiredService<IWolverineRuntime>()
        .Agents.AllLocallyOwnedDatabaseIds()
        .Any(id => id.Name.EqualsIgnoreCase(database.Identifier)),
    staleThreshold: TimeSpan.FromSeconds(30),
    includeExternallyManaged: true);
 ... (truncated)

Commits viewable in [compare view](https://github.com/JasperFx/marten/compare/V9.20.2...V9.21.0).
</details>

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>

[dependabot]

Looks like these dependencies are no longer updatable, so this is no longer needed.