Skip to content

Bump the nuget-minor-patch group with 10 updates - #207

Closed
dependabot[bot] wants to merge 2 commits into
mainfrom
dependabot/nuget/nuget-minor-patch-9a8d4a0398
Closed

dependabot[bot] wants to merge 2 commits into
mainfrom
dependabot/nuget/nuget-minor-patch-9a8d4a0398

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 5, 2026 •

Copy link
Copy Markdown
Contributor

Updated AndreGoepel.Core from 1.0.2 to 1.0.3.

Release notes

Sourced from AndreGoepel.Core's releases.

1.0.3

What's Changed

Full Changelog: andregoepel/core@v1.0.2...v1.0.3

Commits viewable in compare view.

Updated AndreGoepel.Design.Blazor from 1.6.5 to 1.6.7.

Release notes

Sourced from AndreGoepel.Design.Blazor's releases.

1.6.7

What's Changed

Full Changelog: andregoepel/design-blazor@v1.6.6...v1.6.7

1.6.6

What's Changed

Full Changelog: andregoepel/design-blazor@v1.6.5...v1.6.6

Commits viewable in compare view.

Updated AndreGoepel.Marten.Configuration from 1.2.2 to 1.2.3.

Release notes

Sourced from AndreGoepel.Marten.Configuration's releases.

1.2.3

What's Changed

Full Changelog: andregoepel/marten-configuration@v1.2.2...v1.2.3

Commits viewable in compare view.

Updated AndreGoepel.Marten.Testing from 1.2.1 to 1.2.2.

Release notes

Sourced from AndreGoepel.Marten.Testing's releases.

1.2.2

What's Changed

Full Changelog: andregoepel/marten-testing@v1.2.1...v1.2.2

Commits viewable in compare view.

Updated Marten from 9.30.0 to 9.31.2.

Release notes

Sourced from Marten's releases.

9.31.2

A diagnostics-only patch release. No behavioural change to the write path.

A failed batched write now reports the SQL that failed

When a batched write failed, Marten threw a MartenCommandException whose message rendered an empty command text. Reported from the field on an async projection:

Marten Command Failure:$ $ $ 42601: syntax error at end of input POSITION: 56
Error trying to build and apply changes to event subscription MyProjection:All

The $ $ $ is the message template interpolating a command that was always null. ReadNpgsqlCommand() looks for an NpgsqlCommand in exception.Data, and on the ExecuteBatchPagesAsync path there is no single command to put there — AutoClosingLifetime transformed the exception with nothing recorded at all, and WrapAndThrow(NpgsqlBatch, ...) recorded the batch under a key that nothing ever read.

The practical consequence: the offending SQL was unrecoverable from the exception and from the logs, for every async projection write. That is precisely the situation where hand-written SQL — a QueueSqlCommand, a custom IStorageOperation, a projection side effect — turns out to be malformed, and the one thing you need to see is the statement.

MartenCommandException now recovers the SQL from three sources, in order:

  1. the NpgsqlCommand it was handed;
  2. NpgsqlException.BatchCommand — Npgsql identifies the exact statement the server rejected when the failure came out of a batch execution;
  3. an NpgsqlBatch recorded on the exception.

The recovered statement is also exposed on a new MartenCommandException.CommandText property, so it can be read programmatically rather than scraped out of the message.

AutoClosingLifetime executes its batches inline rather than through handleCommandException, so it now records its batch. The other three connection lifetimes already routed through WrapAndThrow(NpgsqlBatch, ...) and only needed a reader for the key they were already writing.

Two guardrails worth knowing about: a batch renders at most five statements, so a 500-operation projection page cannot turn one failure into an unreadable log entry, and the whole resolution is wrapped in a catch — building a diagnostic must never replace the real failure.

Also released as 8.38.1 on the 8.x line.

9.31.1

A single-fix patch release that moves Marten to JasperFx 2.61.0, picking up the source generator fix for JasperFx/jasperfx#​733. Weasel stays on 9.29.0.

Self-aggregating snapshots silently skipped a constructor-based Create

A self-aggregating snapshot may declare its Create handler as an event-shaped constructor, public Foo(FooCreated e), instead of a named static Create. That works on its own. Adding a ShouldDelete method to the same aggregate switched the source generator to a different emitter — one that built its dispatch switch from named conventional methods only — so the constructor's event type got no case arm at all.

Nothing failed loudly. The generated code compiled, the constructor never ran, and the next Apply-only event built the aggregate through RuntimeHelpers.GetUninitializedObject, skipping every field initializer. The visible symptom was an ApplyEventException wrapping a NullReferenceException out of an Apply that appended to a collection property:

JasperFx.Events.Daemon.ApplyEventException: Failure to apply event #​0 Id(...)
 ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at TempGuidAggregate.Apply(TagAdded @​event)

The quieter outcome, where no Apply happens to dereference anything, is a silently blank aggregate.

Both documented workarounds — converting the constructor to a static Create, or registering the delete through DeleteEvent<T>() instead of ShouldDelete — become unnecessary on this release.

The same omission was also in the generated EventTypes property on every self-aggregating path, including the ones whose dispatch was already correct, so an aggregate with a constructor Create and no ShouldDelete gains its creating event in that list here too.

Covered by Bug_jasperfx_733_event_constructor_create_with_should_delete across inline, async and live aggregation, plus the delete arm itself. See #​5322.

9.31.0

Every fix in this release removes a silent wrong answer — not a crash, not an exception, but a plausible-looking result that was wrong with nothing to tell you so. A stream folded into partial aggregates. Paging that returned arbitrary pages. Monitoring that went dark rather than broken. A search reading a key that did not exist. An index that was never created.

Plus one genuinely new feature: weighted full text search with relevance ranking.

New: weighted full text indexes and ts_rank ordering

A full text index used to concatenate its members into one flat vector, so a match in a title was exactly as relevant as a match in a long description. Now it can be weighted, and ranked:

opts.Schema.For<Achievement>().WeightedFullTextIndex(idx => idx
    .Weighted(a => a.Title, TextSearchWeight.A)
    .Weighted(a => a.Tagline, TextSearchWeight.B)
    .Weighted(a => a.Description, TextSearchWeight.C));

var results = await session.Query<Achievement>()
    .Where(a => a.WebStyleSearch(term))
    .OrderByTextRank(term, TextSearchFunction.WebStyle)
    .ToListAsync();

The rank resolves the same tsvector the Where clause matched on, read from the index definition. That is the load-bearing design constraint rather than an implementation detail: a rank computed over a different vector than the filter matched on returns rows in an order that looks plausible and means nothing — a far quieter failure than returning the wrong rows.

Requires Weasel 9.29.0 (weasel#​541), which made it possible to index an expression that is already a tsvector. See the full text documentation for the costs worth knowing first — GIN cannot order, so this is a post-filter sort; and adding weights to an existing index drops and recreates it.

Silent wrong answers, fixed

Async projections folded one stream into several partial aggregates (#​5305, originally #​4085). When a stream's events disagreed about tenant_id, the daemon sliced it per tenant and applied the pieces over each other, so an Apply saw a document with every property at its default. Marten had set ForceSingleTenancy since the original fix, but TenantedEventSlicer honoured that flag on only one of its two overloads — and the async daemon reaches the other one. The flag was being set on precisely the path that could not read it. Fixed upstream in JasperFx 2.58.0.

OrderBy after a GroupJoin/SelectMany was dropped from the SQL (#​5311). Silently, and with Skip/Take it was worse: OFFSET and LIMIT were emitted while the ordering was not, and unordered paging in PostgreSQL has no stable row order — so rows repeat across pages while others never appear. Where on a bare-side selector and Count over a join were wrong in the same surface and are fixed too.

A store with monitoring off dropped the monitoring columns another store had added (#​5309). Two DocumentStores over one DatabaseSchemaName that disagreed about EnableExtendedProgressionTracking kept stripping each other's mt_event_progression columns — last writer wins, silent on both sides. A service beside a seeder or a reporting job is an ordinary arrangement, and neither was doing anything wrong. The shape of that table no longer depends on configuration at all.

Full text search rewrote JSON keys, not just the column (#​5314, thanks @​mlh758). A member whose serialized name contained data produced d.data ->> 'd.data' — a key that does not exist. Two quiet consequences: that member contributed nothing to the search, and the expression no longer matched the index, so the GIN index could not serve the query either.

A second full text index over different members was silently discarded (#​5315). Index names derive from the table rather than from the members, so two FullTextIndex() calls collided by construction and the second was thrown away — never registered, never created, never searched. Ambiguity is now refused with an explanatory exception instead of resolved by declaration order.

A DCB boundary aggregate failed far from its cause (JasperFx 2.60.0). An identity-less [BoundaryAggregate] folded by Evolve(IEvent) got no evolver and no diagnostic, surfacing much later as FetchForWritingByTags<T> throwing "No source-generated dispatcher found" — naming neither the type nor the reason. Now it generates, and a [BoundaryAggregate] with nothing to fold events with is reported as JFXEVT007.

A DCB tag version was captured after the events were read (#​5300). Two batched statements do not share a READ COMMITTED snapshot, so the version could reflect a concurrent append. Captured before the read now.

Also in this release

  • A projection-run CLI command arrives with JasperFx 2.60.0 and needs no Marten change — every host referencing JasperFx.Events picks it up. It replays one projection over a stream slice or DCB tag match and prints per-event before/after state, writing nothing.
  • Bug_5268's concurrent index test no longer depends on how much unrelated transaction load happens to be in flight (#​5308), so validating a dependency bump by running the whole suite at once is trustworthy again.
  • BuildSlicer now agrees with FetchAsyncPlan about global aggregates (#​5307). Alignment rather than a fix — no reachable corruption depended on it, and the reasoning is written down at the call site so the question does not have to be reconstructed next time.

Upgrade notes

OrderByFragment.Expressions changed from List<string> to List<ISqlFragment>. A public API break, deliberately taken: an ordering could not carry a parameter while the clause was a list of strings, which is why the older ngram ranking inlines its search term rather than binding it. Nothing outside Marten's own LINQ internals is likely to touch this type, but it is a compile break if you did.

... (truncated)

Commits viewable in compare view.

Updated Marten from 9.30.0 to 9.32.0.

Release notes

Sourced from Marten's releases.

9.32.0

Two coordinated feature waves against JasperFx.Events 2.63.0, plus the compliance enrollments that keep Marten, Polecat, and Fisher synchronized.

Broadened event querying (jasperfx#​737 → #​5330 / #​5331)

QueryEventsAsync / EventQuery now supports inclusive timestamp windows (TimestampFrom/TimestampTo), inclusive sequence windows (SequenceFloor/SequenceCeiling), multiple event type aliases (EventTypeNames, union with the single EventTypeName), and DCB tag conditions folded into the query (TagConditions — the TagTables and HStore modes both translate through the same SQL as QueryByTagsAsync). Results are contractually ordered sequence-ascending; TotalCount counts matches across all pages.

⚠️ Behavior change: a metadata filter (CorrelationId, CausationId, UserName) against a store that has not enabled the corresponding capture column now throws NotSupportedException naming the field — previously the filter was silently dropped and unfiltered results were returned as if filtered.

Stream state querying + the compaction watermark (jasperfx#​740 → #​5333 / #​5334)

QueryStreamStates(tenantId?) exposes a real IQueryable<StreamState> over mt_streams — every public member translates in Where(), including AggregateType == typeof(X) (resolved through the stored type alias) and the new CompactedVersion watermark, so a compaction policy predicate like s.AggregateType == typeof(Order) && s.Version - s.CompactedVersion > 1000 && !s.IsArchived runs server-side. mt_streams gains an additive compacted_version bigint NOT NULL DEFAULT 0 column (Weasel migration; expect a one-time schema-touch burst on a first local test run against pre-existing schemas), and CompactStreamAsync records the watermark in the same unit of work — monotonically (greatest()), so a replayed lower-cutoff compaction can never move it backwards. Untranslatable members and a tenant scope on a non-conjoined store refuse by name, never silently match-all.

CLI + compliance

The JasperFx.Events event-query and stream-query commands are covered end-to-end against Marten (first CLI-execution tests in the repo). Compliance: EventQueryCompliance (41 facts) and StreamStateQueryCompliance (15) enrolled; the full compliance namespace runs 388/388 on net9.0 and net10.0.

Note for code importing both Marten and JasperFx.Events.Documents: extension-style ToListAsync over the stream queryable is ambiguous (CS0121) — call the JasperFx extensions explicitly.

🤖 Generated with Claude Code

9.31.2

A diagnostics-only patch release. No behavioural change to the write path.

A failed batched write now reports the SQL that failed

When a batched write failed, Marten threw a MartenCommandException whose message rendered an empty command text. Reported from the field on an async projection:

Marten Command Failure:$ $ $ 42601: syntax error at end of input POSITION: 56
Error trying to build and apply changes to event subscription MyProjection:All

The $ $ $ is the message template interpolating a command that was always null. ReadNpgsqlCommand() looks for an NpgsqlCommand in exception.Data, and on the ExecuteBatchPagesAsync path there is no single command to put there — AutoClosingLifetime transformed the exception with nothing recorded at all, and WrapAndThrow(NpgsqlBatch, ...) recorded the batch under a key that nothing ever read.

The practical consequence: the offending SQL was unrecoverable from the exception and from the logs, for every async projection write. That is precisely the situation where hand-written SQL — a QueueSqlCommand, a custom IStorageOperation, a projection side effect — turns out to be malformed, and the one thing you need to see is the statement.

MartenCommandException now recovers the SQL from three sources, in order:

  1. the NpgsqlCommand it was handed;
  2. NpgsqlException.BatchCommand — Npgsql identifies the exact statement the server rejected when the failure came out of a batch execution;
  3. an NpgsqlBatch recorded on the exception.

The recovered statement is also exposed on a new MartenCommandException.CommandText property, so it can be read programmatically rather than scraped out of the message.

AutoClosingLifetime executes its batches inline rather than through handleCommandException, so it now records its batch. The other three connection lifetimes already routed through WrapAndThrow(NpgsqlBatch, ...) and only needed a reader for the key they were already writing.

Two guardrails worth knowing about: a batch renders at most five statements, so a 500-operation projection page cannot turn one failure into an unreadable log entry, and the whole resolution is wrapped in a catch — building a diagnostic must never replace the real failure.

Also released as 8.38.1 on the 8.x line.

9.31.1

A single-fix patch release that moves Marten to JasperFx 2.61.0, picking up the source generator fix for JasperFx/jasperfx#​733. Weasel stays on 9.29.0.

Self-aggregating snapshots silently skipped a constructor-based Create

A self-aggregating snapshot may declare its Create handler as an event-shaped constructor, public Foo(FooCreated e), instead of a named static Create. That works on its own. Adding a ShouldDelete method to the same aggregate switched the source generator to a different emitter — one that built its dispatch switch from named conventional methods only — so the constructor's event type got no case arm at all.

Nothing failed loudly. The generated code compiled, the constructor never ran, and the next Apply-only event built the aggregate through RuntimeHelpers.GetUninitializedObject, skipping every field initializer. The visible symptom was an ApplyEventException wrapping a NullReferenceException out of an Apply that appended to a collection property:

JasperFx.Events.Daemon.ApplyEventException: Failure to apply event #​0 Id(...)
 ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at TempGuidAggregate.Apply(TagAdded @​event)

The quieter outcome, where no Apply happens to dereference anything, is a silently blank aggregate.

Both documented workarounds — converting the constructor to a static Create, or registering the delete through DeleteEvent<T>() instead of ShouldDelete — become unnecessary on this release.

The same omission was also in the generated EventTypes property on every self-aggregating path, including the ones whose dispatch was already correct, so an aggregate with a constructor Create and no ShouldDelete gains its creating event in that list here too.

Covered by Bug_jasperfx_733_event_constructor_create_with_should_delete across inline, async and live aggregation, plus the delete arm itself. See #​5322.

9.31.0

Every fix in this release removes a silent wrong answer — not a crash, not an exception, but a plausible-looking result that was wrong with nothing to tell you so. A stream folded into partial aggregates. Paging that returned arbitrary pages. Monitoring that went dark rather than broken. A search reading a key that did not exist. An index that was never created.

Plus one genuinely new feature: weighted full text search with relevance ranking.

New: weighted full text indexes and ts_rank ordering

A full text index used to concatenate its members into one flat vector, so a match in a title was exactly as relevant as a match in a long description. Now it can be weighted, and ranked:

opts.Schema.For<Achievement>().WeightedFullTextIndex(idx => idx
    .Weighted(a => a.Title, TextSearchWeight.A)
    .Weighted(a => a.Tagline, TextSearchWeight.B)
    .Weighted(a => a.Description, TextSearchWeight.C));

var results = await session.Query<Achievement>()
    .Where(a => a.WebStyleSearch(term))
    .OrderByTextRank(term, TextSearchFunction.WebStyle)
    .ToListAsync();

The rank resolves the same tsvector the Where clause matched on, read from the index definition. That is the load-bearing design constraint rather than an implementation detail: a rank computed over a different vector than the filter matched on returns rows in an order that looks plausible and means nothing — a far quieter failure than returning the wrong rows.

Requires Weasel 9.29.0 (weasel#​541), which made it possible to index an expression that is already a tsvector. See the full text documentation for the costs worth knowing first — GIN cannot order, so this is a post-filter sort; and adding weights to an existing index drops and recreates it.

Silent wrong answers, fixed

Async projections folded one stream into several partial aggregates (#​5305, originally #​4085). When a stream's events disagreed about tenant_id, the daemon sliced it per tenant and applied the pieces over each other, so an Apply saw a document with every property at its default. Marten had set ForceSingleTenancy since the original fix, but TenantedEventSlicer honoured that flag on only one of its two overloads — and the async daemon reaches the other one. The flag was being set on precisely the path that could not read it. Fixed upstream in JasperFx 2.58.0.

OrderBy after a GroupJoin/SelectMany was dropped from the SQL (#​5311). Silently, and with Skip/Take it was worse: OFFSET and LIMIT were emitted while the ordering was not, and unordered paging in PostgreSQL has no stable row order — so rows repeat across pages while others never appear. Where on a bare-side selector and Count over a join were wrong in the same surface and are fixed too.

A store with monitoring off dropped the monitoring columns another store had added (#​5309). Two DocumentStores over one DatabaseSchemaName that disagreed about EnableExtendedProgressionTracking kept stripping each other's mt_event_progression columns — last writer wins, silent on both sides. A service beside a seeder or a reporting job is an ordinary arrangement, and neither was doing anything wrong. The shape of that table no longer depends on configuration at all.

Full text search rewrote JSON keys, not just the column (#​5314, thanks @​mlh758). A member whose serialized name contained data produced d.data ->> 'd.data' — a key that does not exist. Two quiet consequences: that member contributed nothing to the search, and the expression no longer matched the index, so the GIN index could not serve the query either.

A second full text index over different members was silently discarded (#​5315). Index names derive from the table rather than from the members, so two FullTextIndex() calls collided by construction and the second was thrown away — never registered, never created, never searched. Ambiguity is now refused with an explanatory exception instead of resolved by declaration order.

A DCB boundary aggregate failed far from its cause (JasperFx 2.60.0). An identity-less [BoundaryAggregate] folded by Evolve(IEvent) got no evolver and no diagnostic, surfacing much later as FetchForWritingByTags<T> throwing "No source-generated dispatcher found" — naming neither the type nor the reason. Now it generates, and a [BoundaryAggregate] with nothing to fold events with is reported as JFXEVT007.

A DCB tag version was captured after the events were read (#​5300). Two batched statements do not share a READ COMMITTED snapshot, so the version could reflect a concurrent append. Captured before the read now.

Also in this release

  • A projection-run CLI command arrives with JasperFx 2.60.0 and needs no Marten change — every host referencing JasperFx.Events picks it up. It replays one projection over a stream slice or DCB tag match and prints per-event before/after state, writing nothing.
  • Bug_5268's concurrent index test no longer depends on how much unrelated transaction load happens to be in flight (#​5308), so validating a dependency bump by running the whole suite at once is trustworthy again.
  • BuildSlicer now agrees with FetchAsyncPlan about global aggregates (#​5307). Alignment rather than a fix — no reachable corruption depended on it, and the reasoning is written down at the call site so the question does not have to be reconstructed next time.

Upgrade notes

OrderByFragment.Expressions changed from List<string> to List<ISqlFragment>. A public API break, deliberately taken: an ordering could not carry a parameter while the clause was a list of strings, which is why the older ngram ranking inlines its search term rather than binding it. Nothing outside Marten's own LINQ internals is likely to touch this type, but it is a compile break if you did.

... (truncated)

Commits viewable in compare view.

Updated Quartz.Extensions.Hosting from 3.20.0 to 3.20.1.

Release notes

Sourced from Quartz.Extensions.Hosting's releases.

3.20.1

Quartz.NET 3.20.1 is a maintenance release: every change is a bug fix, the public API is untouched (the baselines did not move), and the schema is 3.20's. Most of it was found while 4.0 was being finished and rehearsed — a fix that turned out to be as old as 3.x was ported here rather than left on the newer line — and one item comes from a production application's 3.19.1 → 4.0 upgrade that also read on 3.x. Eight of the fixes change what a running scheduler does, each marked Behavior change worth noting below.

dotnet add package Quartz --version 3.20.1

What changed

Landed on the branch since 3.20.0:

  • A DailyTimeIntervalTrigger stored through the default Newtonsoft path reads back again — TimeOfDay has no parameterless constructor, so with the trigger converters off (the default) EndTimeOfDay threw "Unable to find a constructor" and StartTimeOfDay silently read back as midnight. A converter scoped to TimeOfDay-typed members reads both forms; nothing about what is written changed, so every blob a released 3.20 wrote is one this reads. (9ee33fec17, fixes #​3508)
  • A daily time interval trigger never fires before it starts — StartTimeUtc kept its milliseconds while the fire times are counted in whole seconds, so a start of 22:50:00.68 could produce a first fire at 22:50:00.000. Start and end are rounded down to the second when set, as CronTriggerImpl always did. (cc051a7788, #​3386)
  • A trigger with nothing left to fire is finished however its last firing ended — a firing abandoned by a failing job listener, a veto or a shutdown left a one-shot trigger waiting for ever in RAMJobStore and as a permanent COMPLETE row in the ADO store. Both stores finish it now. (0af9431d3e, #​3507)
  • The in-memory store applies the misfire policy of a trigger it unblocks — a trigger blocked behind a [DisallowConcurrentExecution] job is neither acquired nor swept, so the completion that unblocks it is the first thing that can settle its missed fire time; RAMJobStore now does what JobStoreSupport.RecoverUnblockedMisfires always did. (c9d8658a35, #​3463)
  • Pausing a trigger no longer throws its error away — RAMJobStore wrote Paused over Error, so a failed trigger vanished from every listing once its group was paused and ResetTriggerFromErrorState had nothing to reset. It now pauses only what the ADO store pauses: waiting, acquired and blocked triggers. (a56a16ca0c)
    • Behavior change worth noting: 3.20.0's notes listed this among the store-parity alignments left off 3.x; it is on 3.x now.
  • Rescheduling recomputes a fire time its new start time left behind — RescheduleJob advanced a never-fired repeating simple trigger's start time past a next fire time it kept, so it fired at the stale time and again at its start. (3e086091fc, #​3554)
  • A trigger loaded beside its job by the XML processor is scheduled once, not twice — every such trigger was scheduled and then immediately rescheduled with overwrite-existing-data on, and a repeating trigger that starts now fired twice milliseconds apart. (f25080cef6, #​3554)
  • Both serializers read a string dictionary written by the other — a Dictionary<string, string> job-data value written by the Newtonsoft package carried a $type the System.Text.Json reader handed back as an entry, and one written by System.Text.Json came back from Json.NET as a JObject. Both readers read both shapes; neither writer changed. (83ba80ce79, part of #​3582)
  • Schema validation checks QRTZ_SIMPROP_TRIGGERS too — a database missing only that table passed validation and failed on the first calendar-interval, daily-time-interval or recurrence trigger insert. (b33c70487b, #​3564)
  • The 3.20 index-alignment scripts name the 4.0 index script that supersedes them (4b3c43a90e); untagged builds from the branch say 3.20 (0e2f6bcf31); the XML scheduling integration test opens its own fixture's data source (4c07210199, #​3573).

Ported from 4.0:

  • A job listener that throws before it returns no longer wedges the firing — a synchronous throw from JobToBeExecuted escaped as itself rather than the exception the run shell catches, so TriggeredJobComplete was never reached: the trigger stayed acquired and, for a [DisallowConcurrentExecution] job, every sibling trigger stayed blocked; the firing was also listed as executing for the life of the process. (port of #​3502)
  • MySQL's misfire sweep reads the index that has the shape it needs — both misfire statements and the count every misfire pass starts with were forced onto IDX_QRTZ_T_NFT_ST_MISFIRE, whose second column is compared with <> and stops the seek dead. Measured on 4.x against 100,000 triggers: the count 111 ms → 0.7 ms, the sweep 66 ms → 0.7 ms. No schema change. (port of #​3608)
  • A process that cannot load the job classes can edit their schedules — RescheduleJob and UpdateTriggerDetails on the ADO store resolved the job's class to decide whether the new trigger could run, and failed in an administration node without the assembly. Both read the job's two attribute flags from QRTZ_JOB_DETAILS now, so the decision is right without the class and a placeholder ITypeLoadHelper — which decided that question by whether the placeholder carried the attribute — is no longer needed. (port of #​3705)
  • A transaction the database rolled back is retried whatever the driver calls it — SQLSTATE class 40 (40001, 40P01; 40002 excepted) is transient. Firebird reports a write conflict that way with IsTransient false, and MySql.Data its 1213 deadlock. (port of #​3454)
    • Behavior change worth noting: those failures are retried where they were treated as permanent.
  • A persistent store refuses a repeat interval it cannot hold — a SimpleTrigger interval finer than a millisecond was stored as 0, read back as zero, and left the trigger in ACQUIRED for good behind a divide-by-zero the store logged and swallowed. It is refused on write now, naming the trigger and the column; RAMJobStore keeps accepting it. (port of #​3673)
    • Behavior change worth noting: storing such a trigger throws where it used to succeed and leave the trigger stuck; a trigger already stored with a zero interval is unaffected by this release.
  • System.Text.Json refuses a job-data value it cannot read back — a List<string> or a nested object serialized happily and threw on the next read with the blob already in the database, and every later acquisition of the trigger failed on it. A value that would be stored as a JSON array, or as an object other than a Dictionary<string, string>, is refused before the first byte is written, naming the entry and its type. Anything stored as a number or a string — every numeric type, DateTime, Guid, byte[], Uri — still round-trips exactly as before. (port of #​3495)
    • Behavior change worth noting: such a value is a JsonSerializationException at store time, where it used to be a blob the next read failed on. The refusal also covers three shapes that did not throw before but never came back as themselves either — a non-generic Hashtable, an object whose properties are all strings, and a JobDataMap nested inside a JobDataMap — each of which the reader handed back as a Dictionary<string, string>. Store one of those as a string of your own making.
  • A daily time interval trigger stops at its end time — an EndTimeUtc falling between two fire times of the same day let the trigger go on firing until the daily window closed, and FinalFireTimeUtc reported that close even when it was a day past the end. (port of the daily half of #​3458)
    • Behavior change worth noting: a trigger whose end time fell mid-window fires fewer times than on 3.20.
  • NativeJob no longer deadlocks a child that writes more than a pipe buffer — both streams were redirected whether or not consumeStreams asked for them to be read, so with the defaults a chatty process blocked on its own write and the job's synchronous wait held a worker for ever. Nothing is redirected unless consumed. (port of the rc.1 fix)
  • A connection that cannot join the ambient transaction is refused — EnlistConnection inside a TransactionScope took a Microsoft.Data.Sqlite connection on trust, and SQLite cannot enlist, so every statement committed on the spot and a rolled-back scope left the schedule behind. EnlistTransaction(DbTransaction) still works there. (port of the beta.1 fix)
  • The misfire threshold instant itself is late, on every store — a trigger due at exactly now - MisfireThreshold was a misfire to RAMJobStore and to the ADO store's single-trigger path but not to its periodic sweep; the sweep says <= now and the acquisition predicate moved to > in step. (port of #​3462)
    • Behavior change worth noting: a trigger due at exactly that instant is swept as a misfire where the periodic sweep used to pass over it, so its misfire instruction now applies to it.
  • A job-data number written with a decimal comma is unreadable, not a hundredfold of itself — "3,14" read as 314 from the floating-point accessors while GetInt threw. (port of the beta.1 fix)
    • Behavior change worth noting: GetDouble and GetFloat throw a FormatException for such a string where they used to answer a number a hundred times too large.
  • A group matcher containing [ matches literally on SQL Server — T-SQL reads [ as a character class in LIKE; it is escaped on that dialect only, because the standard forbids escaping a non-wildcard elsewhere. (port of the rc.1 fix)
    • Behavior change worth noting: a matcher whose value contains [ matches the groups it names rather than the character class T-SQL read it as, so it can list, pause, resume or delete a different set than on 3.20.
  • DirectoryScanJob stores its previous scan as something a job store can write — it kept a List<FileInfo> under [PersistJobDataAfterExecution], which System.Text.Json cannot write, so its first firing on such a store failed to persist. A legacy list already in a running scheduler is still read. (port of the rc.1 fix)
  • DirectoryScanJob runs at all on 3.20 — it read its optional job-data keys with GetString, which throws for a key that is not there, so a job configured without a directory provider or listener name failed on every firing with KeyNotFoundException. Found while porting the previous item; the optional keys are asked for rather than read.
  • SelectSchedulerStateRecords binds its parameters in statement order — only a provider with BindByName off could ever have noticed. (port of the alpha.3 fix)

Public API

Unchanged. No signature was added, altered or removed, and the PublicApiTest baselines did not move.
... (truncated)

Commits viewable in compare view.

Updated Quartz.Serialization.SystemTextJson from 3.20.0 to 3.20.1.

Release notes

Sourced from Quartz.Serialization.SystemTextJson's releases.

3.20.1

Quartz.NET 3.20.1 is a maintenance release: every change is a bug fix, the public API is untouched (the baselines did not move), and the schema is 3.20's. Most of it was found while 4.0 was being finished and rehearsed — a fix that turned out to be as old as 3.x was ported here rather than left on the newer line — and one item comes from a production application's 3.19.1 → 4.0 upgrade that also read on 3.x. Eight of the fixes change what a running scheduler does, each marked Behavior change worth noting below.

dotnet add package Quartz --version 3.20.1

What changed

Landed on the branch since 3.20.0:

  • A DailyTimeIntervalTrigger stored through the default Newtonsoft path reads back again — TimeOfDay has no parameterless constructor, so with the trigger converters off (the default) EndTimeOfDay threw "Unable to find a constructor" and StartTimeOfDay silently read back as midnight. A converter scoped to TimeOfDay-typed members reads both forms; nothing about what is written changed, so every blob a released 3.20 wrote is one this reads. (9ee33fec17, fixes #​3508)
  • A daily time interval trigger never fires before it starts — StartTimeUtc kept its milliseconds while the fire times are counted in whole seconds, so a start of 22:50:00.68 could produce a first fire at 22:50:00.000. Start and end are rounded down to the second when set, as CronTriggerImpl always did. (cc051a7788, #​3386)
  • A trigger with nothing left to fire is finished however its last firing ended — a firing abandoned by a failing job listener, a veto or a shutdown left a one-shot trigger waiting for ever in RAMJobStore and as a permanent COMPLETE row in the ADO store. Both stores finish it now. (0af9431d3e, #​3507)
  • The in-memory store applies the misfire policy of a trigger it unblocks — a trigger blocked behind a [DisallowConcurrentExecution] job is neither acquired nor swept, so the completion that unblocks it is the first thing that can settle its missed fire time; RAMJobStore now does what JobStoreSupport.RecoverUnblockedMisfires always did. (c9d8658a35, #​3463)
  • Pausing a trigger no longer throws its error away — RAMJobStore wrote Paused over Error, so a failed trigger vanished from every listing once its group was paused and ResetTriggerFromErrorState had nothing to reset. It now pauses only what the ADO store pauses: waiting, acquired and blocked triggers. (a56a16ca0c)
    • Behavior change worth noting: 3.20.0's notes listed this among the store-parity alignments left off 3.x; it is on 3.x now.
  • Rescheduling recomputes a fire time its new start time left behind — RescheduleJob advanced a never-fired repeating simple trigger's start time past a next fire time it kept, so it fired at the stale time and again at its start. (3e086091fc, #​3554)
  • A trigger loaded beside its job by the XML processor is scheduled once, not twice — every such trigger was scheduled and then immediately rescheduled with overwrite-existing-data on, and a repeating trigger that starts now fired twice milliseconds apart. (f25080cef6, #​3554)
  • Both serializers read a string dictionary written by the other — a Dictionary<string, string> job-data value written by the Newtonsoft package carried a $type the System.Text.Json reader handed back as an entry, and one written by System.Text.Json came back from Json.NET as a JObject. Both readers read both shapes; neither writer changed. (83ba80ce79, part of #​3582)
  • Schema validation checks QRTZ_SIMPROP_TRIGGERS too — a database missing only that table passed validation and failed on the first calendar-interval, daily-time-interval or recurrence trigger insert. (b33c70487b, #​3564)
  • The 3.20 index-alignment scripts name the 4.0 index script that supersedes them (4b3c43a90e); untagged builds from the branch say 3.20 (0e2f6bcf31); the XML scheduling integration test opens its own fixture's data source (4c07210199, #​3573).

Ported from 4.0:

  • A job listener that throws before it returns no longer wedges the firing — a synchronous throw from JobToBeExecuted escaped as itself rather than the exception the run shell catches, so TriggeredJobComplete was never reached: the trigger stayed acquired and, for a [DisallowConcurrentExecution] job, every sibling trigger stayed blocked; the firing was also listed as executing for the life of the process. (port of #​3502)
  • MySQL's misfire sweep reads the index that has the shape it needs — both misfire statements and the count every misfire pass starts with were forced onto IDX_QRTZ_T_NFT_ST_MISFIRE, whose second column is compared with <> and stops the seek dead. Measured on 4.x against 100,000 triggers: the count 111 ms → 0.7 ms, the sweep 66 ms → 0.7 ms. No schema change. (port of #​3608)
  • A process that cannot load the job classes can edit their schedules — RescheduleJob and UpdateTriggerDetails on the ADO store resolved the job's class to decide whether the new trigger could run, and failed in an administration node without the assembly. Both read the job's two attribute flags from QRTZ_JOB_DETAILS now, so the decision is right without the class and a placeholder ITypeLoadHelper — which decided that question by whether the placeholder carried the attribute — is no longer needed. (port of #​3705)
  • A transaction the database rolled back is retried whatever the driver calls it — SQLSTATE class 40 (40001, 40P01; 40002 excepted) is transient. Firebird reports a write conflict that way with IsTransient false, and MySql.Data its 1213 deadlock. (port of #​3454)
    • Behavior change worth noting: those failures are retried where they were treated as permanent.
  • A persistent store refuses a repeat interval it cannot hold — a SimpleTrigger interval finer than a millisecond was stored as 0, read back as zero, and left the trigger in ACQUIRED for good behind a divide-by-zero the store logged and swallowed. It is refused on write now, naming the trigger and the column; RAMJobStore keeps accepting it. (port of #​3673)
    • Behavior change worth noting: storing such a trigger throws where it used to succeed and leave the trigger stuck; a trigger already stored with a zero interval is unaffected by this release.
  • System.Text.Json refuses a job-data value it cannot read back — a List<string> or a nested object serialized happily and threw on the next read with the blob already in the database, and every later acquisition of the trigger failed on it. A value that would be stored as a JSON array, or as an object other than a Dictionary<string, string>, is refused before the first byte is written, naming the entry and its type. Anything stored as a number or a string — every numeric type, DateTime, Guid, byte[], Uri — still round-trips exactly as before. (port of #​3495)
    • Behavior change worth noting: such a value is a JsonSerializationException at store time, where it used to be a blob the next read failed on. The refusal also covers three shapes that did not throw before but never came back as themselves either — a non-generic Hashtable, an object whose properties are all strings, and a JobDataMap nested inside a JobDataMap — each of which the reader handed back as a Dictionary<string, string>. Store one of those as a string of your own making.
  • A daily time interval trigger stops at its end time — an EndTimeUtc falling between two fire times of the same day let the trigger go on firing until the daily window closed, and FinalFireTimeUtc reported that close even when it was a day past the end. (port of the daily half of #​3458)
    • Behavior change worth noting: a trigger whose end time fell mid-window fires fewer times than on 3.20.
  • NativeJob no longer deadlocks a child that writes more than a pipe buffer — both streams were redirected whether or not consumeStreams asked for them to be read, so with the defaults a chatty process blocked on its own write and the job's synchronous wait held a worker for ever. Nothing is redirected unless consumed. (port of the rc.1 fix)
  • A connection that cannot join the ambient transaction is refused — EnlistConnection inside a TransactionScope took a Microsoft.Data.Sqlite connection on trust, and SQLite cannot enlist, so every statement committed on the spot and a rolled-back scope left the schedule behind. EnlistTransaction(DbTransaction) still works there. (port of the beta.1 fix)
  • The misfire threshold instant itself is late, on every store — a trigger due at exactly now - MisfireThreshold was a misfire to RAMJobStore and to the ADO store's single-trigger path but not to its periodic sweep; the sweep says <= now and the acquisition predicate moved to > in step. (port of #​3462)
    • Behavior change worth noting: a trigger due at exactly that instant is swept as a misfire where the periodic sweep used to pass over it, so its misfire instruction now applies to it.
  • A job-data number written with a decimal comma is unreadable, not a hundredfold of itself — "3,14" read as 314 from the floating-point accessors while GetInt threw. (port of the beta.1 fix)
    • Behavior change worth noting: GetDouble and GetFloat throw a FormatException for such a string where they used to answer a number a hundred times too large.
  • A group matcher containing [ matches literally on SQL Server — T-SQL reads [ as a character class in LIKE; it is escaped on that dialect only, because the standard forbids escaping a non-wildcard elsewhere. (port of the rc.1 fix)
    • Behavior change worth noting: a matcher whose value contains [ matches the groups it names rather than the character class T-SQL read it as, so it can list, pause, resume or delete a different set than on 3.20.
  • DirectoryScanJob stores its previous scan as something a job store can write — it kept a List<FileInfo> under [PersistJobDataAfterExecution], which System.Text.Json cannot write, so its first firing on such a store failed to persist. A legacy list already in a running scheduler is still read. (port of the rc.1 fix)
  • DirectoryScanJob runs at all on 3.20 — it read its optional job-data keys with GetString, which throws for a key that is not there, so a job configured without a directory provider or listener name failed on every firing with KeyNotFoundException. Found while porting the previous item; the optional keys are asked for rather than read.
  • SelectSchedulerStateRecords binds its parameters in statement order — only a provider with BindByName off could ever have noticed. (port of the alpha.3 fix)

Public API

Unchanged. No signature was added, altered or removed, and the PublicApiTest baselines did not move.
... (truncated)

Commits viewable in compare view.

Updated Radzen.Blazor from 11.2.8 to 11.3.2.

Release notes

Sourced from Radzen.Blazor's releases.

11.3.2

11.3.2 - 2026-09-04

Improvements

  • DataGrid auto-scrolls horizontally while a column header is dragged near either edge of the scroll container, so a column can be dropped onto a destination outside the visible area in one drag, in LTR and RTL (#​2690).
  • Demos link every component page to a markdown twin of its API reference.

Fixes

  • DataGrid, DataList, PivotDataGrid, DropDown, ListBox and DropDownDataGrid execute bound IQueryable data synchronously again, as in 11.2.8 and earlier. The asynchronous execution introduced in 11.3.0 released the renderer while a query still held the DbContext, so any other component on the page that enumerated a query from the same context during render, such as a DropDown in a FilterTemplate, threw "There is already an open DataReader associated with this Connection" or "A second operation was started on this context instance". Applications that need asynchronous execution use LoadData.
  • DataGrid reports zero items instead of one for an empty virtualized data source (#​2691).
  • DataGrid no longer leaks document mouse listeners when a column drag starts again before the previous one ended, and a quick click on Blazor Server no longer leaves a ghost header following the pointer until the next mouseup.
  • Tooltip measures the popup with the resolved side's arrow class before placing it, so a Bottom tooltip that falls back to Top no longer ends inside its target and flickers near the bottom of the viewport. https://forum.radzen.com/t/21690

11.3.1

11.3.1 - 2026-09-03

Improvements

  • DataGrid draws the focused cell during keyboard navigation and shows keyboard focus on grids without row selection (#​2698).
  • DataGrid filters array-valued properties on their element type, supports collection-level IsNull/IsEmpty filters without FilterProperty and null-guards Any/All item filters (#​2696).
  • Demos add a UI Blocks Gallery with 24 new block categories (#​2695).

Fixes

  • DataGrid, DropDown, ListBox and DropDownDataGrid no longer invoke application callbacks such as RowExpand, LoadChildData, RowSelect, RowEdit, Sort, Filter, Page and Change while their own asynchronous IQueryable load still holds the query provider. Pages sharing a DbContext threw "A second operation was started on this context instance" since 11.3.0. https://forum.radzen.com/t/21689
  • DataGrid tints frozen cells together with the rest of the focused row on grids without row selection.
  • Accordion and AutoComplete no longer throw "The ParameterView instance can no longer be read because it has expired" when Multiple or SelectedItem change at runtime. https://forum.radzen.com/t/21688

11.3.0

11.3.0 - 2026-09-02

Improvements

  • RadzenDataGrid, RadzenDataList, RadzenDropDown, RadzenListBox, RadzenDropDownDataGrid, RadzenPivotDataGrid - bound IQueryable count and materialization execute asynchronously when the provider supports it (e.g. Entity Framework Core) with no extra package or registration. Operations are serialized per query provider so components sharing a DbContext never issue concurrent operations on it, untranslatable queries fall back to the synchronous path and the Radzen.Blazor.DisableAsyncQueryExecution AppContext switch opts out entirely. Fixes #​2688.
  • RadzenDataGrid - render optimizations: reduced per-cell rendering overhead and row edit state is cascaded only while editing. Thanks to @​pianomanjh!
  • RadzenCheckBoxList, RadzenRadioButtonList, RadzenTree - selection membership is resolved once per render instead of scanning the selection per item, and compiled property getters are cached by signature - significantly faster rendering with large item and selection counts. Thanks to @​pianomanjh!
  • RadzenDatePicker - O(1) selected-day membership in Multiple-mode calendar. Thanks to @​pianomanjh!
  • RadzenPanelMenu - automatic indentation for nested items at any depth. Fixes #​2675.
  • QueryableExtension - filter MethodInfo lookups are cached and OrderBy expressions are parsed in a single pass. Thanks to @​pianomanjh!
  • Premium themes updated.

Fixes

  • RadzenRangeNavigator - no longer throws ArithmeticException when rendered before its width has been measured; NiceNumber now treats a non-finite range like a zero one. Fixes #​2693. Thanks to @​pianomanjh!
  • RadzenDataGrid - an empty grid with virtualization enabled no longer reports 1 record in the paging summary. Fixes #​2691.
  • RadzenPivotDataGrid - initially bound filter values are honored after interactive changes and no longer trigger a redundant Reload on initial render. Thanks to @​pianomanjh!
  • RadzenDropDown, RadzenListBox - filtering a virtualized list down to no matches no longer crashes the Blazor Server circuit.

Commits viewable in compare view.

Updated WolverineFx.Marten from 6.32.0 to 6.33.0.

Release notes

Sourced from WolverineFx.Marten's releases.

6.33.0

The headline is a new package. WolverineFx.AI makes a one shot LLM call an ordinary Wolverine message: durable, outbox enrolled, retried by the same rules as everything else, and testable without a model anywhere in sight.

WolverineFx.AI (new package)

An LlmCallout is a message. Return one from a handler next to your storage action and it is enrolled in that handler's outbox, so a callout cannot fire for a transaction that did not commit and cannot be lost to a restart in between. The model's answer comes back as an ordinary cascading message, with an ordinary handler, an ordinary retry policy, and its own place in the correlation chain. (closes #​4227)

  • Spend guardrails as middleware on the callout queue. LlmBudget.MaximumPromptCharacters refuses a runaway prompt before your provider is ever called; MaximumTokensPerWindow refuses callouts once the node has burned its allowance. Both dead letter rather than retry, and so does an answer that cannot be parsed into the response type you asked for -- retrying either is the runaway spend the budget exists to stop.
  • A scripted IChatClient for testing. StubChatClient exercises a callout's whole round trip with no key, no network and no model.
  • Trim and AOT clean, guarded by a Wolverine.AI.AotSmoke project under TrimMode=full that CI runs. (closes #​4230)
  • Documentation for tuning it, new in this release: how to control parallelism against your provider, why the answer has its own queue with its own settings, and how to bring your own error handling on both sides.

The package references only the Microsoft.Extensions.AI abstractions, never a vendor SDK. The provider -- Anthropic, OpenAI, Azure, Ollama -- and any middleware over it stay your choice.

Fixes

  • A node no longer sweeps up its own in-flight stop as a wedged shard. An event-subscription agent could end up running on two nodes at once while wolverine_nodes credited only one, so nothing in the system could ever stop the extra copy. (closes #​4240)
  • Node record descriptions no longer overflow the column and fail the insert. An AssignmentChanged description carries an agent URI, a schema name and a destination node, which on a real cluster overran the description column and failed the whole AgentCommand batch behind it. MySQL was worst hit at VARCHAR(255). (closes #​4246)
  • DataAnnotations validation works with ServiceLocationPolicy.NotAllowed -- on HTTP endpoints and, now, on message handlers. Under the Wolverine 6 default this made the validation middleware unusable and threw at bootstrap. (closes #​4238)
  • A failed EF Core rollback no longer displaces the exception that caused it. (closes #​4239)
  • Wolverine parameter attributes work on gRPC before/after hooks -- [Entity], [All], [Queryable], [WriteAggregate] and the rest. (closes #​3935)
  • An application-wide default duplicate status code via opts.DefaultDuplicateStatusCode, and deduplication refusals now advertise their problem document in OpenAPI.
  • Concurrent IHost.StopAsync no longer tears the agents down twice.

Upgrade note

6.33.0 requires Weasel 9.30.0, and that raises the GH-4246 fix from "new databases only" to "existing ones too": the schema differ now compares character lengths, so a widened varchar is no longer invisible to it and an existing table is corrected in place by an ALTER TABLE ... MODIFY that keeps its rows.

Worth knowing before you upgrade: that comparison runs in both directions. Width drift that was previously invisible now generates ALTERs, and a model narrower than an existing column will emit a narrowing ALTER that can fail on real data. Sizes that are not character lengths -- a MySQL int(11) display width, a decimal precision, a datetime fsp -- are still ignored.

Dependencies

JasperFx 2.60.0, Marten 9.30.0, Polecat 5.21.1, Fisher 1.0.6, Weasel 9.30.0.

Commits viewable in compare view.

Updated WolverineFx.RuntimeCompilation from 6.32.0 to 6.33.0.

Release notes

Sourced from WolverineFx.RuntimeCompilation's releases.

6.33.0

The headline is a new package. WolverineFx.AI makes a one shot LLM call an ordinary Wolverine message: durable, outbox enrolled, retried by the same rules as everything else, and testable without a model anywhere in sight.

WolverineFx.AI (new package)

An LlmCallout is a message. Return one from a handler next to your storage action and it is enrolled in that handler's outbox, so a callout cannot fire for a transaction that did not commit and cannot be lost to a restart in between. The model's answer comes back as an ordinary cascading message, with an ordinary handler, an ordinary retry policy, and its own place in the correlation chain. (closes #​4227)

  • Spend guardrails as middleware on the callout queue. LlmBudget.MaximumPromptCharacters refuses a runaway prompt before your provider is ever called; MaximumTokensPerWindow refuses callouts once the node has burned its allowance. Both dead letter rather than retry, and so does an answer that cannot be parsed into the response type you asked for -- retrying either is the runaway spend the budget exists to stop.
  • A scripted IChatClient for testing. StubChatClient exercises a callout's whole round trip with no key, no network and no model.
  • Trim and AOT clean, guarded by a Wolverine.AI.AotSmoke project under TrimMode=full that CI runs. (closes #​4230)
  • Documentation for tuning it, new in this release: how to control parallelism against your provider, why the answer has its own queue with its own settings, and how to bring your own error handling on both sides.

The package references only the Microsoft.Extensions.AI abstractions, never a vendor SDK. The provider -- Anthropic, OpenAI, Azure, Ollama -- and any middleware over it stay your choice.

Fixes

  • A node no longer sweeps up its own in-flight stop as a wedged shard. An event-subscription agent could end up running on two nodes at once while wolverine_nodes credited only one, so nothing in the system could ever stop the extra copy. (closes #​4240)
  • Node record descriptions no longer overflow the column and fail the insert. An AssignmentChanged description carries an agent URI, a schema name and a destination node, which on a real cluster overran the description column and failed the whole AgentCommand batch behind it. MySQL was worst hit at VARCHAR(255). (closes #​4246)
  • DataAnnotations validation works with ServiceLocationPolicy.NotAllowed -- on HTTP endpoints and, now, on message handlers. Under the Wolverine 6 default this made the validation middleware unusable and threw at bootstrap. (closes #​4238)
  • A failed EF Core rollback no longer displaces the exception that caused it. (closes #​4239)
  • Wolverine parameter attributes work on gRPC before/after hooks -- [Entity], [All], [Queryable], [WriteAggregate] and the rest. (closes #​3935)
  • An application-wide default duplicate status code via opts.DefaultDuplicateStatusCode, and deduplication refusals now advertise their problem document in OpenAPI.
  • Concurrent IHost.StopAsync no longer tears the agents down twice.

Upgrade note

6.33.0 requires Weasel 9.30.0, and that raises the GH-4246 fix from "new databases only" to "existing ones too": the schema differ now compares character lengths, so a widened varchar is no longer invisible to it and an existing table is corrected in place by an ALTER TABLE ... MODIFY that keeps its rows.

Worth knowing before you upgrade: that comparison runs in both directions. Width drift that was previously invisible now generates ALTERs, and a model narrower than an existing column will emit a narrowing ALTER that can fail on real data. Sizes that are not character lengths -- a MySQL int(11) display width, a decimal precision, a datetime fsp -- are still ignored.

Dependencies

JasperFx 2.60.0, Marten 9.30.0, Polecat 5.21.1, Fisher 1.0.6, Weasel 9.30.0.

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 <dependency name> major version will close this group updat...

Description has been truncated

Bumps AndreGoepel.Core from 1.0.2 to 1.0.3
Bumps AndreGoepel.Design.Blazor from 1.6.5 to 1.6.7
Bumps AndreGoepel.Marten.Configuration from 1.2.2 to 1.2.3
Bumps AndreGoepel.Marten.Testing from 1.2.1 to 1.2.2
Bumps Marten to 9.31.2, 9.32.0
Bumps Quartz.Extensions.Hosting from 3.20.0 to 3.20.1
Bumps Quartz.Serialization.SystemTextJson from 3.20.0 to 3.20.1
Bumps Radzen.Blazor from 11.2.8 to 11.3.2
Bumps WolverineFx.Marten from 6.32.0 to 6.33.0
Bumps WolverineFx.RuntimeCompilation from 6.32.0 to 6.33.0

---
updated-dependencies:
- dependency-name: AndreGoepel.Core
  dependency-version: 1.0.3
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-minor-patch
- dependency-name: AndreGoepel.Design.Blazor
  dependency-version: 1.6.7
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-minor-patch
- dependency-name: Radzen.Blazor
  dependency-version: 11.3.2
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-minor-patch
- dependency-name: AndreGoepel.Marten.Configuration
  dependency-version: 1.2.3
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-minor-patch
- dependency-name: Marten
  dependency-version: 9.31.2
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-minor-patch
- dependency-name: AndreGoepel.Marten.Testing
  dependency-version: 1.2.2
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-minor-patch
- dependency-name: Marten
  dependency-version: 9.32.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-minor-patch
- dependency-name: Quartz.Extensions.Hosting
  dependency-version: 3.20.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-minor-patch
- dependency-name: Quartz.Serialization.SystemTextJson
  dependency-version: 3.20.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-minor-patch
- dependency-name: WolverineFx.Marten
  dependency-version: 6.33.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-minor-patch
- dependency-name: WolverineFx.RuntimeCompilation
  dependency-version: 6.33.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-minor-patch
...

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 Sep 5, 2026
@dependabot @github

dependabot Bot commented on behalf of github Sep 12, 2026

Copy link
Copy Markdown
Contributor Author

Superseded by #209.

@dependabot dependabot Bot closed this Sep 12, 2026
@dependabot
dependabot Bot deleted the dependabot/nuget/nuget-minor-patch-9a8d4a0398 branch September 12, 2026 02:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment