Skip to content

Bump the dotnet-production group with 7 updates - #17

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/dot-config/dotnet-production-877a96b21a
Closed

Bump the dotnet-production group with 7 updates#17
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/dot-config/dotnet-production-877a96b21a

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Updated cake.tool from 6.2.0 to 6.3.0.

Release notes

Sourced from cake.tool's releases.

6.3.0

As part of this release we had 60 issues closed.

Bugs

Features

Improvements

Contributors

6 contributors made this release possible.

devlead augustoproiete peymanr34 patriksvensson paulomorgado perclausen
... (truncated)

Commits viewable in compare view.

Updated coverlet.collector from 10.0.1 to 10.1.0.

Release notes

Sourced from coverlet.collector's releases.

10.1.0

Improvements

  • Publish Microsoft.Testing.Platform coverage messages from coverlet.MTP #​2019
  • Implement dynamic exclusion filters for assemblies (Coverlet.MTP) #​1946
  • Replace legacy .sln files with modern .slnx format #​1966
  • coverlet.console: add trace diagnostics and actionable warnings for instrumentation/hit/empty-result failures #​2005
  • Relax auto-property skip logic and improve coverage for records #​1941

Fixed

  • Fix coverlet.MTP does not collect coverage on the .NET Framework portion of a large project #​1980 #​1967
  • Fix Regression in branch coverage for lambda expressions #​1938
  • Fix When using "is" with "or" in pattern matching, branch coverage is lower than normal #​1979
  • Fix silent zero coverage on .NET Framework since 8.0.0 #​1985 by @​tobiwae
  • Fix Race condition between ProcessExit hit-file write and out-of-proc coverage read causes EndOfStreamException #​1987 #​1988 by @​bkoelman
  • Fix Regression TypeInitializationException when targeting .NET Framework - Could not load type 'System.Collections.Concurrent.ConcurrentBag #​2010
  • Fix use --config-file CLI arg in coverlet.MTP #​2030 by alexthornton1
  • Fix silently empty coverage for shared-framework assemblies missing from compileLibraries #​2032 by @​Eljees

Diff between 10.0.1 and 10.1.0

Commits viewable in compare view.

Updated Marten from 9.33.0 to 9.43.0.

Release notes

Sourced from Marten's releases.

9.43.0

Bumps the JasperFx family to 2.78.0 and lands four issues, one of them a data-corruption fix worth reading even if you skip the rest.

Fixes

#​5539 — a zero-event quick append could permanently wedge a stream. mt_quick_append_events called with zero events read mt_streams.version without a lock and ended with a blind write-back, so under READ COMMITTED it could overwrite a concurrent appender's version and leave the stream row below its own events. Every later append then computed a version that already existed and failed on pk_mt_events_stream_and_version — permanently, with no recovery short of repairing the row by hand. A non-empty append could never do this: its first insert collides on that same primary key and rolls back, which is why only the empty call was exposed. The write-back is now skipped when nothing was appended, and uses greatest() so it can never lower a version whoever calls it.

Field context: a production console on 9.32.0 sat at mt_streams.version 608676 against max(mt_events.version) 608678 for 42 days, roughly 28 failed appends a minute. If you have a stream failing every append on that constraint, this is likely why.

#​5541 — ShardState.LastUpdated, liveness rather than progress. Sequence cannot distinguish caught up with nothing new from no longer maintained: both hold the same number forever. The progression row's last_updated now reaches ShardState and ProjectionProgressRow, and — the part that needed a product change — an idle high-water cycle now restamps the HighWaterMark row. Previously an idle cycle issued no SQL at all, so that stamp froze at the last real mark advance and read as "abandoned weeks ago" on a perfectly healthy store. The restamp never touches last_seq_id, so it cannot nudge the mark.

Diagnostics surface (monitoring consoles)

#​5543 — IDocumentStoreDiagnostics adopts the defined contract (jasperfx#​870). Five behaviours were previously "whatever the store happened to do", and Marten was on the wrong side of all five:

Before Now
Soft deletes returned as live excluded unless asked; a load by id returns the row flagged
Hierarchies every sub-class in the table filtered to the requested type; each row reports its own
Missing tenant all tenants the default tenant
"" tenant a tenant literally named "" the default tenant
Ids id::text = @​id converted to the stored identity type — uses the PK index, matches an upper-case Guid

Also: LoadDocumentAsync returning StoredDocument with metadata, populated DocumentQueryResult.Documents, a new IDocumentStoreDiagnosticsWriter (save-from-JSON and delete through a normal session, with an expected-version guard), DocumentStoreUsage.SerializerCasing, and structured index / duplicated-field descriptors. Query criteria Marten cannot yet translate are refused rather than silently ignored.

#​5544 — DocumentQueryOptions.AllTenants. The explicit replacement for the all-tenants read that #​5543 removed. Conjoined tenancy reads every tenant, ordered by tenant then id so paging cannot repeat a row. A store spreading tenants across databases refuses rather than quietly returning only the default tenant's rows.

⚠️ Behaviour change for diagnostics consumers: a null or blank TenantId now means the default tenant, not every tenant. If you relied on the old behaviour, set AllTenants = true.

Also

#​5542 — asynchronous aggregate events are ordered by stream sequence.

Internals: a diagnostic document read now resolves a tenant's database through TryFindDatabase rather than FindOrCreateDatabase, so asking a read-only question about an unknown tenant can no longer provision that tenant.

9.42.0

Mostly fixes, and two of them only became visible once the one underneath them was gone. Nothing here requires action on upgrade unless you use IsolationLevel.RepeatableRead or above, or batch a FetchForWriting for an Async-snapshot aggregate.

Migrations settle again on a long schema name

#​5536. ApplyAllDatabaseChangesOnStartup() against an already-migrated schema could fail with:

42710: constraint "fkey_mt_events_stream_id" for relation "mt_events" already exists

The foreign key was not the problem. PostgreSQL truncates identifiers at 63 characters, so a longer DatabaseSchemaName was stored truncated while Marten went on querying for the name it had asked for — found none of its objects, concluded they were all missing, and re-issued DDL the server resolved against the truncated schema, where they already existed. The first apply passed and the second failed, with an error pointing nowhere near the schema name.

DatabaseSchemaName is now truncated to 63 characters so the two sides agree. This does not move anyone's data: the server was already truncating it, and Marten now simply uses the name the server actually stored. Two distinct long names sharing their first 63 characters still collide, exactly as they already do in PostgreSQL.

The apply-changes lock waits long enough to be useful

#​5529. The advisory lock guarding startup migrations retried on a fixed 50 / 100 / 250ms ladder — about 400ms to win it. That is ample for the multi-replica rolling deploy it was designed for, where the loser only has to outlast a peer's finished migration. It is not enough when more than one store shares a database inside one host, where the loser has to outlast a migration that is still running: it failed startup, and the message's own advice (ResourceMigrationFailureMode.ContinueOnFailures) would have started the application against a half-migrated schema.

New knob, defaulting to 10 seconds:

opts.ApplyChangesLockTimeout = 30.Seconds();   // many stores on one database, or a large schema

This was held back until it could be measured. While weasel#​659 was unfixed the lock was stranded by any migration that threw, and a longer wait provably changed nothing. Weasel 9.37.0 releases it on the failure path, and only then did the residue show up as a genuine race worth budgeting for.

⚠️ No write retry from RepeatableRead upwards

#​5528, completing what 9.41.0 started. Marten's retry replays the operations it has already computed, not the application code that computed them — and from RepeatableRead up, the session's transaction is pinned to one snapshot. So any successful replay commits decisions derived from a snapshot that no longer exists. That is exactly the silent lost update 9.41.0 fixed for 40001, and 40P01 (deadlock) had the same flaw for the same structural reason.

The write-retry pipeline is now skipped entirely for RepeatableRead, Serializable and Snapshot. This is deliberately broader than refusing those two SQLSTATEs: class 53, 55, 57P03 and 58 all abort a snapshot-holding transaction too, so singling out class 40 would have left the identical hole open one error code over.

If you use those isolation levels, expect to see failures surface that were previously retried away. Handle them by re-reading and recomputing — the only place a snapshot conflict can be resolved. ReadCommitted is the default and is unchanged: it takes a fresh snapshot per statement, so replaying precomputed SQL still means what it meant, and every existing application keeps full retry behaviour.

A batched Async-snapshot FetchForWriting says what it needs

#​5535. For an aggregate projected with ProjectionLifecycle.Async, the non-exclusive FetchForWriting wraps its reads in begin transaction isolation level repeatable read read only … end so they share one snapshot — and PostgreSQL accepts that only as the first statement in a transaction. Enlisted after anything else in a batch, it failed at Execute() with 25001: SET TRANSACTION ISOLATION LEVEL must be called before any query, naming an isolation level the caller never mentioned and saying nothing about ordering. Nothing about CreateBatchQuery() hints that one of its members has to go first.

It is now refused at the enlisting call, with a message that names the aggregate and the constraint. The position that worked still works.

Dependencies

Weasel 9.37.0, whose weasel#​659 is the reason most of #​5529 went away: ApplyAllConfiguredChangesToDatabaseAsync released the global migration lock only on its success paths, so a migration that threw left it held and locked every other replica out of migrating — while the node that stranded it reported nothing. Disposing the connection was not enough, because Npgsql resets a pooled connection when it is next used rather than when it is returned, so the lock outlived the apply for as long as that connection sat idle.

Also in 9.37.0, and worth reading if you use them: SQL Server 2025 JSON indexes are no longer emitted as DROP INDEX on every apply (weasel#​661), Oracle descending indexes and co-migrated views settle (weasel#​660), TableDelta.HasChanges() answers instead of throwing for a table that does not exist yet (weasel#​658), and the reconnection loop no longer abandons a connection per attempt (weasel#​664).

Housekeeping

DISABLE_TEST_PARALLELIZATION is gone from the CI workflow and the contributor docs. Nothing ever read it, so it looked like a control and was not one — including to us, while diagnosing #​5529. Test parallelisation is disabled by CollectionBehavior in AssemblyInfo.cs, and both files now say where to change it.

9.41.0

Upgrade if you use IsolationLevel.Serializable. The first item below is a silent lost update, and it has been present since the write-retry pipeline shipped. The two items after it change behaviour you may be relying on.

🛑 Data integrity: Serializable sessions could silently lose an update

#​5528. A session opened with IsolationLevel.Serializable (or RepeatableRead) did not reliably protect against a lost update. PostgreSQL detected the write conflict correctly and Marten discarded the detection by retrying.

Two serializable sessions each load the same document at Amount = 100. One commits 100 - 500. The other should be refused with ConcurrentUpdateException; instead it committed 100 - 350 on top, and the first session's write was gone with no error raised anywhere. From the server's own log:

[14197] ERROR:  could not serialize access due to concurrent update
[14197] ROLLBACK
[14196] BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE    -- the replay
[14196] insert ... on conflict (id) do update ...         -- same values, same mt_version
[14196] COMMIT

WriteRetryClassifier (#​5262) listed 40001 serialization_failure as safe to replay, on the reasoning that the server had rolled the transaction back and said so — which is true, and turned out to be necessary but not sufficient. A replay re-issues the operations already computed, rather than re-running the application code that produced them, and a serialization failure means precisely that the snapshot those operations were derived from is no longer a valid basis for them. The replay opens a new transaction with a fresh snapshot, so the conflict is gone and the write lands.

40001 is now never replayed and surfaces as ConcurrentUpdateException, which is what Marten already translated it to. If you opted into Serializable you should expect to start seeing that exception — handle it by re-reading and recomputing, which is the only place the conflict can be resolved. Nothing inside Marten requests these isolation levels, so the async daemon and every default ReadCommitted session are unaffected.

40P01 deadlock_detected stays retryable deliberately: a deadlock aborts over lock ordering rather than a rejected snapshot, and replaying it is the textbook remedy at ReadCommitted. A deadlock retry under Serializable replays stale-snapshot work for the same structural reason, and the honest fix needs the isolation level plumbed into the classifier — recorded as a known gap rather than guessed at.

This went unnoticed because the test that catches it lives in StressTests, which has had no CI job since 2026-08-08.

⚠️ Behaviour change: the HotCold leadership lock is session-scoped again

#​5526. Events.UseAdvisoryLockTransaction now defaults to false, so HotCold leader election uses a session-scoped pg_try_advisory_lock rather than a transaction-scoped pg_try_advisory_xact_lock. The transaction-scoped lock had been the default since 8.37.3 (April 2026).

The reason is what the transaction-scoped lock costs while it works: the leader holds an open transaction for as long as it holds leadership, which on a long-lived daemon is an indefinitely long-running transaction sitting on the connection — with everything that implies for vacuum and for anything watching transaction age.

The transaction-scoped lock is still the better fit behind PgBouncer in transaction pooling mode, which can hand a session-scoped lock's server connection to another client. If that is your deployment, opt back in explicitly:

builder.Services.AddMarten(opts =>
{
    opts.Connection(connectionString);
    opts.Events.UseAdvisoryLockTransaction = true;
})
.AddAsyncDaemon(DaemonMode.HotCold);

⚠️ Breaking: DefaultTenantUsageDisabledException is no longer a MartenException

#​5514. Marten.Exceptions.DefaultTenantUsageDisabledException now derives from JasperFx.Events.DefaultTenantUsageDisabledException.

JasperFx.Events carries this exception so that code can handle the refusal once across Critter Stack stores, and its own contract is that stores subclass it. Polecat did; Marten did not. The consequence was not an error anywhere — a store-agnostic catch (JasperFx.Events.DefaultTenantUsageDisabledException) compiled, read as if it handled the refusal, and let it through unhandled on Marten only. That is the failure mode this fixes.

Multiple inheritance is not available, so it is one base or the other, and the cross-store catch was judged worth more than the marker base. If you rely on a broad catch (MartenException) to handle this refusal, it will no longer be caught — catch the exception itself, or the JasperFx base. The message is unchanged, including the single-argument overload's behaviour of appending to the standard prefix.

Also gone with the reparenting: the protected (SerializationInfo, StreamingContext) constructor, because the JasperFx base declares none to chain to. Binary serialization of exceptions has been obsolete since .NET 8.
... (truncated)

9.40.0

Minor rather than patch for one reason: the source-generated DetermineAction now decides one action per batch rather than per event. See the behaviour change below before upgrading if you archive streams from a projection.

⚠️ Behaviour changes

Archiving projections: one action per batch, not per event (JasperFx/jasperfx#​889, via the JasperFx 2.75.2 bump). The source-generated DetermineAction used to decide per event; it now decides once per batch. This changes what an archiving projection does when a single batch mixes an archive with later events for the same stream. StreamArchivingCompliance gained facts for it and Marten passes them, but if you depend on the old per-event evaluation, test before upgrading.

TenantIdStyle is now applied where the tenant id is stamped and keyed, not only where a tenant is resolved (#​5516). Under ForceLowerCase, these three previously wrote or matched the raw id:

  • BulkInsertEventsAsync / BulkInsertEventStreamAsync resolved the right database or partition and then stamped the raw id on every mt_streams / mt_events row — rows invisible to any normalised read under conjoined tenancy, and the wrong key inside the right partition under UseTenantPartitionedEvents.
  • TenantIsOneOf(...) filtered on the raw values, so a mixed-case id matched nothing.
  • DeleteAllTenantDataAsync used the raw id as its DELETE ... WHERE tenant_id = :p parameter, so it matched no rows and reported success — the one to look at hardest, since callers are usually honouring an erasure request.

If you have been calling these with mixed-case tenant ids, data already written under the raw casing stays where it is; it will not be found by a normalised read. ForTenant(string) also now normalises its nested-session cache key, which makes ForTenant("RED") and ForTenant("red") one session rather than two.

Event store

  • IEventStore.OpenReadOnlyEventStore(tenantId) is implemented (#​5513). With Advanced.DefaultTenantUsageEnabled = false — the automatic state once database-per-tenant tenancy is configured — the entire IReadOnlyEventStore surface was unreachable, because the tenant-less overload opens the store's default session and is refused before any tenant scope applies. That is why QueryStreamStates(tenantId)'s own parameter could not work around it. A null tenant keeps the previous store-global behaviour.
  • Diagnostic event-store reads answer "no results" instead of throwing (#​5511, #​5512), decided from the database rather than from configuration.
  • Progression and dead-letter reads answer nothing for an event store nothing provisions (#​5509, #​5510).

Diagnosing a missing source-generated dispatcher

The JasperFx 2.75.2 bump (#​5518) carries three changes that came out of #​5495, where a user's aggregates compiled with no dispatcher and the runtime message could not tell them why:

  • The generator now leaves [assembly: JasperFxSourceGeneratorApplied] in every assembly it processes, so "the generator never ran in that assembly" — a csproj problem — is distinguishable at runtime from "the generator ran and declined your type" — a code-shape problem. The exception says which.
  • Two copies of the generator in one compilation no longer collide with CS0433. This happens when a project references the standalone JasperFx.Events.SourceGenerator package as well as Marten, which bundles it: both copies emit identical file paths and the file-scoped evolvers mangle to the same name. If you hit that error — recognisable because it names the same assembly on both sides — remove the standalone package reference; Marten already carries the analyzer.
  • Opt in to a build-time check with <JasperFxEventsRequireSourceGenerator>true</JasperFxEventsRequireSourceGenerator> on projects that declare aggregates, and a missing analyzer becomes build error JFXEVT900 rather than a failure at the first FetchForWriting.

Compliance coverage

Marten is now enrolled in DocumentConjoinedTenancyCompliance (#​5517) — the first shared document coverage of conjoined tenancy on any store — with all 10 facts running. ConjoinedEventTenancyCompliance goes from 16 passing with 2 skipped to 18 passing with none, the two skips having been waiting on the read-only overload above.

Two of these enrollments exposed that Marten's own commit-listener compliance facts had been passing vacuously — the harness never installed the listener the suites register, so "no phantom deletion was reported" was trivially true of a store reporting nothing at all. Fixed in the #​5518 bump; no product change was needed, and both halves of that fact now pass for real.

Dependencies

JasperFx 2.75.2 and Weasel 9.35.2.

Weasel 9.35.x is mostly EF Core and SQL Server work, plus weasel#​634: an exhausted DropSchema retry is now reported instead of returning success.

Docs

The bundled analyzer does flow transitively across a ProjectReference (#​5508) — the composite-configuration page claimed the opposite. The claim was true of the standalone analyzer package, which Marten sets PrivateAssets="all" on, but #​4557 bundles the analyzer DLL into Marten's own package and that copy flows.

9.39.1

What's Changed

Full Changelog: JasperFx/marten@V9.39.0...v9.39.1

9.39.0

Security release

This release fixes two critical SQL injection vulnerabilities in Marten's LINQ provider. Both were reported privately and are disclosed today alongside this version. If your application routes untrusted input into either surface below, upgrade.

GHSA-q4xm-rhx9-xjm4 — SQL injection via a GroupBy HAVING operand (critical)

Affects 9.13.0 – 9.38.0. Fixed in 9.39.0.

A GroupBy(...).Where(g => ...) HAVING comparison rendered its constant or closure-captured operand with ToString() and appended it to the command text with no quoting, escaping, or parameterization. Because Marten put no quotes around the operand at all, an attacker did not need to break out of a literal — they supplied the entire literal and everything after it.

// `filter` from untrusted input
.GroupBy(x => x.Color).Where(g => g.Max(p => p.Name) == filter)

Impact is filter and authorization bypass, and subquery-based disclosure, at the session's database privilege. Numeric operands were never injectable.

Note on impact: Marten executes through NpgsqlBatch, which refuses multi-statement command text, so stacked-statement modification is not reachable through this sink.

Fix: a HAVING operand is now either SQL derived from the document model or a value from the caller's expression, and those are distinct types rather than both being string. Values always bind as parameters.

GHSA-frqq-p5g3-8jq5 — SQL injection via regConfig on the full-text ranking path (critical)

Affects 9.31.0 – 9.38.0. Fixed in 9.39.0.

OrderByTextRank / ThenByTextRank interpolated the caller-supplied regConfig into SQL as a '...'::regconfig literal with no validation. This is the same class as CVE-2026-45288, returning on a path added after that fix: the validator existed, but as a private member of FullTextWhereFragment, so the ranking path could not reuse it and did not re-implement it.

You are affected only if your application passes untrusted input as the regConfig argument. It is an optional parameter defaulting to english, so most applications never pass it at all.

Fix: the check is now a shared validator, applied in FullTextIndexResolver.ResolveVector — the sink every full-text path funnels through — so present and future callers are covered by construction rather than by remembering. The weighted-index and Marten.PgVector paths were folded onto the same validator.

Previously fixed, disclosed today

Two advisories for vulnerabilities already fixed in earlier releases are published alongside this one:

  • CVE-2026-77574 / GHSA-4jp4-64fp-89g7 (critical) — SQL injection via a non-string constant in a LINQ Select projection. Fixed in 9.15.3.
  • GHSA-3vp4-34pf-2rcw (high) — SQL injection through a tenant id used as a PostgreSQL partition suffix, under sharded tenancy with UseTenantPartitionedEvents. Fixed in 9.22.1.

If you are on a version older than those, upgrade.

Bug fixes

  • #​5473 — on the rich append path, the optimistic-concurrency exception is now built from the StreamAction rather than by regex over the PostgreSQL error detail. Id, AggregateType and the expected version are now correct regardless of whether Npgsql redacted the detail — which it does unless the connection string carries Include Error Detail=true, so this was the common production case. The fallback message no longer passes PostgreSQL's own text through.
  • #​5479 — a tenant that exists but has been disabled now throws DisabledTenantException instead of UnknownTenantIdException, so an operator who disabled a tenant is no longer told it does not exist. The new type derives from UnknownTenantIdException, so existing catch blocks and OnException<T>() policies keep working.
  • #​5469 — fixed the outer projection of a GroupJoin/SelectMany, and GROUP BY rendering over a join.
  • #​5470 — duplicated-field column names are quoted in closed-shape document storage.

Diagnostics and messages

... (truncated)

9.38.0

Eight changes since 9.37.0. Most of this release is silent-wrongness: a permanent sequence gap that stalls the async daemon, telemetry spans attached to the wrong parent, a DbContext nothing ever disposed, and a vector projection that embedded stale text. Three of them were reported from production by the community.

⚠️ Behaviour change

A VectorProjection declaring MapFromAggregate registered anything other than Async is now refused when the store is built (#​5451, #​5468). The class remarks always said Async was required; nothing enforced it, so an Inline registration built without complaint and then embedded text that missed the event that triggered it. Measured: the first save wrote no row at all, because live aggregation reads committed events and the stream had none yet; every later save wrote the state as of the previous event. The content hash recorded that stale text as current and nothing failed.

If you have such a registration it will now fail at DocumentStore.For(...) with a message naming MapFromAggregate and ProjectionLifecycle.Async. Event-mapped vector projections registered Inline are unaffected and remain supported.

Event store

  • A failed batch no longer leaves a permanent gap in the event sequence (#​5454, #​5456). Under QuickWithServerTimestamps — the V9 default — a StartStream took a per-event INSERT route whose seq_id came from an inlined nextval() that nothing read back. The events kept Sequence 0, and tombstone creation skips exactly those, so any failure later in the same batch (a losing UpdateRevision, a duplicate document INSERT) rolled back with sequence numbers drawn and nothing to fill them. The async daemon's high-water detector then stalled for every tenant in the database until it had seen the gap for StaleSequenceThreshold. A StartStream now goes through the same mt_quick_append_events function an ordinary append already used, which returns its sequence numbers. Reported and fixed by @​vpetrevski.

  • mt_quick_append_events no longer writes a new stream's mt_streams row twice (#​5464). It inserted the row with version 0 and then let the trailing UPDATE set the final version — two heap tuples and two WAL records per stream creation, in one transaction, where nothing outside it could observe the intermediate value. This became the default stream-creation path with #​5456, so it was worth removing. A one-event StartStream measured 471µs on the old per-event route, 511µs through the function, and 480µs with this change (PostgreSQL 17.10, medians of 3). FetchForWriting against a stream that does not exist yet gets the same saving.

Projections and read models

  • An EF Core projection's DbContext is disposed (#​5457, #​5466). EfCoreProjectionStorage owns a context built once per tenant per batch, and nothing disposed it on any path — IProjectionStorage<,> declares no disposal contract, so the type that owned it had nothing to hook. Disposal now belongs to the transaction participant, whose lifetime already equals a batch. A second, unconditional leak is fixed alongside it: the live-aggregation fallback registered its owner only when the session was an ITransactionParticipantRegistrar, and a plain IQuerySession — what AggregateStreamAsync passes — is not one, so nobody released an eagerly-opened connection. Reported by @​wpei-infotrack, with investigation from @​arnelirobles.

  • An absent key no longer projects as an explicit JSON null in a Select() (#​5461, #​5462).

Telemetry

  • Marten activities attach to the current activity, not to its parent (#​5459, #​5465). MartenTracing passed parentActivity?.ParentId to ActivitySource.StartActivity, which parents a span to the parent of the activity it is handed — its grandparent. With an incoming Server/Consumer span carrying a remote traceparent, every marten.connection span hung off the sending service's span instead of the one doing the work. It stayed hidden because it is invisible in the two easy cases: with no ambient activity, or with an ambient root, ParentId is null and ActivitySource falls back to Activity.Current, which is the right answer by accident. Diagnosed from the source by @​bohdan-hukivskyi.

Documentation

  • Unit testing event-sourced handlers with StubEventStream is now documented (#​5455, #​5458, #​5463). Also fixes StubEventStream(aggregate, StoreOptions), which built a second EventGraph so MapEventType aliases never reached it.

  • The pgvector docs no longer describe the ef_search cap that 9.37 removed (#​5452, #​5467), including the non-obvious case that a hybrid search asks for its CandidateDepth rather than its limit and so reaches pgvector's 1000-row ceiling at a limit above 250. Contributed by @​arnelirobles.

Dependencies

JasperFx and JasperFx.Events 2.73.2; Weasel 9.32.0.

9.37.0

Eighteen commits, and almost all of them are Marten.PgVector correctness — found by auditing the search surface 9.36.0 had just shipped. Every one of these was silent: a plausible answer, in a plausible order, that was wrong.

Vector and hybrid search returned the wrong rows
#​5427 Searches skipped Marten's default filters — soft-deleted rows returned, no subclass discriminator, and the tenant filter keyed on the store rather than the document
#​5428 Distance defaulted to Cosine rather than the metric the index declared, so an L2 index was searched by cosine and silently fell back to a sequential scan
#​5419 An indexed search was capped by hnsw.ef_search (default 40) — so it under-returned however large the limit
#​5440 Rows over a document hierarchy came back deserialized as T, never the concrete subtype
#​5433 A wrong-length query vector was cast to its own length rather than refused, so it errored in Postgres' words or answered empty
#​5425 Full text silently fell back to an unindexed whole-document to_tsvector when no index matched the regConfig

VectorProjection wrote the wrong rows
#​5420 Ignored conjoined tenancy — one table keyed on id, so the later tenant's write replaced the earlier one's
#​5439 An inline projection wrote every event under the outer session's tenant, so ForTenant(...) appends landed in the wrong tenant
#​5424 Guid-only, collapsing to Guid.Empty on string-identified streams
#​5422 Page folding — a write and a retraction of one id in a single page left the row in the index

Searches now run through the session (#​5421, #​5423)

The session's connection, transaction, command timeout, resilience pipeline and IMartenSessionLogger. A search on a session inside a caller-managed transaction now sees that session's uncommitted writes, the way Query<T>() does.

⚠️ #​5438's HNSW scan settings are preserved, not weakened. They ride the same batch as the search rather than a transaction of their own — Postgres runs a batch's statements in an implicit transaction, so SET LOCAL still cannot leak onto a pooled connection.

VectorSearchAsync, VectorSearchWithScoresAsync and VectorProjectionSearchAsync gain CancellationToken overloads. Overloads rather than defaulted parameters: an optional argument is compiled into the caller, so widening a shipped signature breaks every assembly that has not been rebuilt.

ColumnWeights is refused, not ignored (#​5446)

HybridSearchOptions gained per-column weights for the text leg (jasperfx#​854, JasperFx 2.72.0). Marten weights at index time through WeightedFullTextIndex, so there is nothing a per-call weight could apply to — and it is refused by name rather than ignored, because a caller who weights a title column and silently gets an unweighted ranking has no way to find out.

Timestamps and the explorer

#​5379 — mt_last_modified no longer jumps by the server's UTC offset when a document is patched. now() at time zone 'utc' strips the offset, and the naive result is re-read in the session's TimeZone: on a UTC+2 database the stored instant was two hours in the past. ⚠️ Only patching was affected — an ordinary Store/SaveChanges takes the column default, which was always correct.

#​5430 (thanks @​erikshafer) covers the event half of the same defect, reached through stream compaction, which #​5445 fixed and left untested — and its assertions run over two time zones in both directions, where a one-sided bound passes against a negative offset.

#​5383 — database-scoped explorer reads, honest store-global reads, and two tenant-scoping defects.

On JasperFx 2.72.0.

9.36.0

Backfilled. This release shipped to NuGet on 2026-09-14 but was never tagged or released here; the notes below were written afterwards from the commits it contains.

Takes Marten.PgVector from a vector search that could not be indexed and could not be called portably, to one that shares the JasperFx.Events.Vectors contracts with Fisher and Polecat, can be served by an HNSW index, returns scores, and fuses with full text.
#​5413 Marten.PgVector on the store-neutral vector contracts, with scored search
#​5414 VectorIndex — declare an HNSW index for a vector search
#​5415 Hybrid search: reciprocal rank fusion over the ts_rank leg and the vector leg
#​5417 Keep the pre-9.36 API working alongside the shared contracts

⚠️ Breaking for Marten.PgVector, and a minor bump anyway

#​5413 deleted that package's own IEmbeddingProvider and DistanceFunction in favour of the shared ones, and removed the dead VectorOn / PgVectorOptions registry, which had no references anywhere including the tests. The Pgvector.Vector overload of VectorSearchAsync was kept and forwards, so the common call site is source-compatible.

Minor rather than major because the whole package family shares one version and Marten itself has no break in this range — a major bump would move every other package for an extension package's API.

⚠️ Read 9.37.0 before adopting this one

The search surface shipped here was audited immediately afterwards, and ten silent defects came out of it — searches that skipped Marten's default filters and returned soft-deleted rows, a distance metric that defaulted to Cosine rather than the one the index declared, an indexed search capped at 40 rows by hnsw.ef_search, a VectorProjection that ignored conjoined tenancy, and more. Every one of them returned a plausible answer in a plausible order.

All of them are fixed in 9.37.0. If you are picking up Marten.PgVector for the first time, start there rather than here.

On the tag. This points at daeb27b5, not at the "Release 9.36.0" commit baf1fc3f. The publish dispatch from the release commit was cancelled, and the run that actually pushed the packages went from daeb27b5 — one commit later, carrying #​5417. The tag names what shipped.

9.35.0

Marten 9.35.0 — Event Model naming, store identity, and idempotent archiving.

⚠️ Behaviour changes

Three, all deliberate. None require a code change to adopt, but each changes what an existing application observes.

1. A store's derived Event Model is now named after your service, not "EventModel" (#​5408).

The store-derived Event Model source fell back to the literal "EventModel" — the one default guaranteed to be wrong for every host. Wolverine names its derived model after JasperFxOptions.ServiceName, and so does Bobcat's spec assembly, so the common case (Wolverine + one Marten store) assembled two models out of the box and had to restate a name it had already declared.

The fallback is now the service name. An explicit name still wins:

services.AddMarten(opts =>
{
    opts.Connection(connectionString);
    opts.EventModelName = "Ledgers";   // optional; defaults to JasperFxOptions.ServiceName
});

If you were relying on the model being called EventModel, set opts.EventModelName = "EventModel" explicitly.

2. The primary store's Subject now follows StoreName (#​5409).

Subject was a literal marten://main that ignored StoreOptions.StoreName, while Identity had always been built from it — so naming a primary store moved one and left the other behind, and Subject is the one consumers key on. Both are now built from StoreName. Tooling that keys on store.Subject (CritterWatch's explorer reads and shard progression ids among them) will see marten://{storename} for a named store where it previously saw marten://main.

A store name is user-supplied text and a uri host is not, so names are sanitized: My Store would otherwise throw UriFormatException and a/b would silently parse its tail as a path. Ordinary names are unchanged.

3. Archiving an already-archived stream is a no-op instead of an error (#​5403).

Under UseArchivedStreamPartitioning, a second archive of the same stream raised 23505 on mt_streams_archived_pkey. This also stalled async single-stream projections with IncludeArchivedEvents = true when they processed an Archived marker after an inline snapshot had already archived the stream. Repeated archiving now succeeds and does nothing.

A genuine collision is still reported: a different active stream reusing an archived stream id still fails, rather than being silently swallowed and losing its metadata.

Fixes and improvements

  • #​5405 / #​5407 — StoreOptions.EventModelName. A host that called AddEventModel("Something", …) assembled two models: its own, and one the store contributed under the default name. The name is configured on StoreOptions and read lazily when the model is assembled, so AddEventModel may be called before or after AddMarten.
  • #​5409 — an ancillary store keeps a name it was given. BuildStoreOptions assigned StoreName both before and after the IConfigureMarten<T> chain, so a contribution that named the store was silently reverted to the marker type's name.
  • #​5403 — partitioned archiving performance. Because is_archived is the list partition key on both mt_streams and mt_events, the archive function's new predicates also let PostgreSQL prune to the active partition, where the previous statements had to consider both.
  • JasperFx 2.69.3. Codegen output is now deterministic (jasperfx#​832) — an ImHashMap keyed by Frame, which does not override GetHashCode, meant statement order followed identity hash codes and varied per process. Every Event Model slice also now carries the store it came from, so two stores projecting a document of the same simple name leave a recorded disagreement rather than one silently winning (jasperfx#​836).

Compatibility

Binary compatible with 9.34.0. The public AddMarten / AddMartenStore<T> surface is unchanged — verified by diffing the extracted signature list against the 9.34.0 tag. New configuration is additive on StoreOptions.

9.34.0

Native AOT support for event-sourced applications, and a round of integrity fixes to the diagnostics and monitoring surface — including one deliberate behaviour change worth reading before upgrading.

Native AOT

Event-sourced applications now run under Native AOT.

  • #​5375 — Closes four generics where the compiler can emit them, so an event-sourced app runs under Native AOT rather than failing at runtime on a construction the trimmer removed.
  • #​5377 — The jsonb containment payload is written by Marten with Utf8JsonWriter instead of round-tripping through the consumer's serializer, removing a reflection-dependent path from AOT reads.

Diagnostics and monitoring

Three fixes to the event store explorer and projection-status APIs. All three are cases where a monitoring read returned something misleading, or changed the system it was observing.

  • #​5400 — Behaviour change. The four explorer read APIs no longer provision anything. They resolved their database through ITenancy.FindOrCreateDatabase, and two tenancy models take the "or create" half literally: ShardedTenancy assigned an unknown tenant to a shard and ran partition + per-tenant sequence DDL for it, and SingleServerMultiTenancy issued CREATE DATABASE for a database named after the id. A console polling a retired or mistyped tenant id therefore brought that tenant — or a whole database — into existence.

    An unrecognized tenant id now throws UnknownTenantIdException, which is what StaticMultiTenancy and MasterTableTenancy already did, so the explorer answers the same way across every tenancy model. Adds the public ITenancy.TryFindDatabase, a read-only counterpart to FindOrCreateDatabase; it is a default interface member, so custom ITenancy implementations keep working unchanged. FindOrCreateDatabase itself is untouched — create-on-demand remains its documented job for real tenant traffic.

    If you call GetRecentStreamsAsync, ReadStreamAsync, QueryByTagsAsync or GetProjectionStatusesAsync with a tenant id that may not exist, it now throws where it previously succeeded.

  • #​5382 — GetProjectionStatusesAsync(ct) threw NotSupportedException on a database-per-tenant store, because a tenant-less call has no default tenant to open a session against. It now answers from the projection registry, so "is this projection still registered?" — the only store-agnostic way to ask, and what orphan detection is built on — works on the store shape that most needs it.

    Note the original issue reported that both overloads threw. Only the tenant-less one did; passing a tenant id or a database identifier from AllDatabases() has always worked and reads real per-database progression.

  • #​5396 — ShardStatus.State reports the state of a reachable daemon instead of always answering Unknown. Unknown now means what it is documented to mean: there is no daemon here to ask.

Correctness

  • #​5386 — The expected version for optimistic concurrency is seeded from a mapped version/revision member, not just the IVersioned marker interface. Thanks to @​JurJean for the report and the original fix.
  • #​5389 — Enum member renames are resolved by asking the serializer, so [JsonStringEnumMemberName] / [EnumMember] names are honored in LINQ translation rather than the CLR member name being assumed.
  • #​5390 — The jsonb containment payload writer handles nested dictionary keys and byte[], and its limits are documented. Thanks to @​erdtsieck.

Event modeling

  • #​5397 — ProjectionEventModelSource is registered from AddMarten and AddMartenStore<T>, so Event Model views resolve from a Marten store without manual wiring.

pgvector

  • #​5399 — Four defects the pgvector import left behind.

Docs and internals

  • #​5381 — Documents PrefixSearch and the session-level full-text search shortcuts.
  • #​5391 — The PostgreSQL setup docs described a Marten that no longer exists (stale PLV8 instructions, a non-functional image override, and an invented build matrix).
  • #​5395 — Enrolls GuidOptimisticConcurrencyCompliance in the shared compliance suite.
  • #​5370, #​5371 — Takes Bobcat's shipped runner adapter and its interceptor opt-in.

Dependencies

  • JasperFx 2.69.1
  • Weasel 9.32.0
    ... (truncated)

Commits viewable in compare view.

Updated Microsoft.NET.Test.Sdk from 18.10.0 to 18.10.1.

Release notes

Sourced from Microsoft.NET.Test.Sdk's releases.

18.10.1

What's Changed

Full Changelog: microsoft/vstest@v18.10.0...v18.10.1

Commits viewable in compare view.

Updated OpenIddict.Core from 7.7.0 to 7.7.1.

Release notes

Sourced from OpenIddict.Core's releases.

7.7.1

This release introduces the following changes:

  • The identity token principal extracted from identity token hints is now correctly restored and returned by ASP.NET Core/OWIN's AuthenticateAsync() API when using pushed authorization requests, authorization request caching or end session request caching.

Commits viewable in compare view.

Updated Weasel.Storage from 9.31.1 to 9.38.0.

Release notes

Sourced from Weasel.Storage's releases.

9.37.0

Five fixes. Full upgrade notes.

⚠️ On SQL Server 2025 with a JSON index? Upgrade before your next migration

A JSON index is in sys.indexes, but its sys.index_columns row carries key_ordinal = 0, which the column query filtered out. The index came back with no columns, matched nothing declared, landed in Indexes.Extras, and was emitted as a DROP INDEX — so every apply silently removed it. JSON indexes are now read through sys.json_indexes / sys.json_index_paths, behind an object_id check so nothing changes on 2022 or earlier. (#​661)

The same change adds JsonIndexDefinition, so CREATE JSON INDEX can be declared, rendered, compared and asserted on like any other schema object.

Oracle: a descending index and co-migrated views never settled

Split commands dropped InitialLONGFetchSize, so ALL_IND_EXPRESSIONS.COLUMN_EXPRESSION and ALL_VIEWS.TEXT — both LONGs — read back empty. PRIORITY DESC came back as its hidden SYS_NC00007$ column and every apply rebuilt the index. It failed only in combination, which is why per-object tests never caught it. Contributed by @​lahma, found through Quartz.NET's Weasel integration. (#​660)

A delta for a table that does not exist answers instead of throwing

TableDelta.HasChanges() threw a NullReferenceException for a table that needs creating — the one case whose answer is unambiguously "yes". It reached operators through Wolverine's resource check, which reports any exception as "Missing known broker resources". SQL Server, PostgreSQL and SQLite. (#​658)

A failed migration no longer strands the global lock

The lock was released only on the success paths, so a migration that threw left it held and locked every other replica out of migrating — while the node that stranded it reported nothing. Disposing the connection was not enough: Npgsql resets a pooled connection when it is next used, not when it is returned, so the session lock outlived the apply for as long as that connection sat idle. (#​659)

The reconnection loop no longer abandons a connection

It replaced conn without disposing what it overwrote, leaving a live connection per attempt for the finalizer to find — against a server that had just refused or terminated one. (#​664)

Minor rather than patch because #​661 adds public API and two of these change migration output — the same reason 9.29.1 was renumbered to 9.30.0.

Verified across both target frameworks and all eight suites against PostgreSQL 17, SQL Server 2022, MySQL 8.0.46, Oracle Free 23 and SQLite: net9.0 3984 passed, net10.0 3980 passed, 0 failed.

9.36.0

A drift release, and one new diagnostic.

Most of 9.36.0 is a single shape of defect found five times over: a model declares something in a spelling the server rewrites when it stores it, so the column or index never matches itself, every migration re-issues DDL that changes nothing, and the delta never settles. MySQL type synonyms, Oracle ANSI type names, Oracle and MySQL index key direction, Oracle index tablespaces and SQL Server CAST all did this.

📖 Full upgrade notes

Read this before upgrading

Oracle: a table with a string column default could not be created at all under the default CreateIfNotExists style — the quote ended the EXECUTE IMMEDIATE literal and the create failed with PLS-00103 (#​643).

Two migrations change behaviour. Changing a computed column's definition now drops and recreates the indexes and foreign keys that depend on it (#​638). That migration used to fail outright on SQL Server, and used to succeed while silently dropping the index on PostgreSQL.

Every drift fix was checked in both directions. The spellings that already reconciled still reconcile, and a genuinely different type, length or direction is still reported as drift. No settled table acquires a new ALTER.

JasperFx 2.76.0 is the new floor, the first release carrying the IAdvisoryLock.FindHolderAsync contract.

Who holds this advisory lock?

#​650. IAdvisoryLock could acquire a distribution lock but not say who holds it — HasLock(lockId) answers only "does this node". So when a projection agent stopped with ProgressionProgressOutOfOrderException, meaning two processes believed they owned the same shard, nothing could name the other one. Under Marten HotCold and Polecat the lock is the authority.

var holder = await advisoryLock.FindHolderAsync(lockId, token.....

_Description has been truncated_

@dependabot
Bump the dotnet-production group with 7 updates
70af4f8 
Bumps cake.tool from 6.2.0 to 6.3.0
Bumps coverlet.collector from 10.0.1 to 10.1.0
Bumps Marten from 9.33.0 to 9.43.0
Bumps Microsoft.NET.Test.Sdk from 18.10.0 to 18.10.1
Bumps OpenIddict.Core from 7.7.0 to 7.7.1
Bumps Weasel.Storage from 9.31.1 to 9.38.0
Bumps xunit.v3 from 4.0.0 to 4.0.1

---
updated-dependencies:
- dependency-name: cake.tool
  dependency-version: 6.3.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dotnet-production
- dependency-name: coverlet.collector
  dependency-version: 10.1.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dotnet-production
- dependency-name: Marten
  dependency-version: 9.43.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dotnet-production
- dependency-name: Microsoft.NET.Test.Sdk
  dependency-version: 18.10.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dotnet-production
- dependency-name: OpenIddict.Core
  dependency-version: 7.7.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dotnet-production
- dependency-name: Weasel.Storage
  dependency-version: 9.38.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: dotnet-production
- dependency-name: xunit.v3
  dependency-version: 4.0.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: dotnet-production
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Oct 1, 2026
@dependabot
dependabot Bot requested a review from meetdhruva as a code owner October 1, 2026 03:21
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code labels Oct 1, 2026
@dependabot @github

dependabot Bot commented on behalf of github Oct 8, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #18.

@dependabot dependabot Bot closed this Oct 8, 2026
@dependabot
dependabot Bot deleted the dependabot/nuget/dot-config/dotnet-production-877a96b21a branch October 8, 2026 03:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@meetdhruva meetdhruva Awaiting requested review from meetdhruva meetdhruva is a code owner

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file .NET Pull requests that update .NET code

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants