Skip to content

chore(deps): Bump the nuget-dependencies group with 15 updates - #49

Merged
JerrettDavis merged 1 commit into
masterfrom
dependabot/nuget/nuget-dependencies-7234630c35
Oct 9, 2026
Merged

chore(deps): Bump the nuget-dependencies group with 15 updates#49
JerrettDavis merged 1 commit into
masterfrom
dependabot/nuget/nuget-dependencies-7234630c35

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 5, 2026

Copy link
Copy Markdown
Contributor

Updated Aspire.Hosting.PostgreSQL from 13.5.4 to 13.6.0.

Release notes

Sourced from Aspire.Hosting.PostgreSQL's releases.

13.6.0

Aspire 13.6.0

Aspire 13.6 brings persistent application history, a refreshed and more interactive dashboard, first-party Java and Rust hosting, and new Azure deployment options. Coordinated .NET builds, portable volume paths, sharper CLI workflows, and more capable editor tooling make it easier to build, debug, and deploy applications across languages.

Highlights

  • 🗃️ Persistent, refreshed dashboard — SQLite-backed telemetry and resource snapshots let you revisit up to ten application runs, with read-only access to completed runs and default retention limits of 100,000 console log messages, structured logs, and traces each. The dashboard now ships as Native AOT and adopts Fluent UI v5 with a collapsible navigation rail.
  • 🖥️ AppHost-owned terminals and database REPLs — Experimental terminal APIs let AppHosts create interactive sessions in a dashboard dock, dialog, or separate window. Opt-in WithRepl() commands open bundled clients for PostgreSQL, MySQL, MongoDB, SQL Server, Redis, and Valkey, while aspire terminal ps and aspire terminal tape play support discovery and repeatable terminal interactions.
  • 🌐 First-party Java and Rust hosting — New Aspire.Hosting.Java and Aspire.Hosting.Rust packages bring Maven, Gradle, Spring Boot, Quarkus, and Cargo applications into the app model, with generated container builds and VS Code debugging. These integrations build on work that originated in the Aspire Community Toolkit.
  • 🛠️ More flexible AppHosts — The prerelease Aspire.Hosting.Dotnet integration coordinates compatible projects into shared restore and build groups and supports .NET SDK container publishing. Portable volume-path environment variables work across local execution and deployment, while TypeScript AppHosts gain standard appsettings.json configuration and Deno runtime support.
  • ⌨️ Sharper CLI workflows — Select launch profiles with aspire run and aspire start, update repository-local CLI manifests with aspire update, create file-based C# AppHosts with aspire init --language csharp --file-based, and export TypeScript API data with aspire sdk export. Terminal commands no longer need a feature flag, Linux certificate trust includes Firefox NSS databases, and aspire stop --force --volumes adds explicit cleanup of Aspire-owned volumes.
  • 💻 More capable VS Code tooling — Coding agents can start and stop AppHosts through the extension, and the Aspire pane exposes deploy, publish, and pipeline actions. Multi-root discovery, worktree-scoped lifecycle operations, preserved launch arguments, clearer debug logs, and missing-debugger guidance make complex workspaces more predictable.
  • ☁️ New Azure options in preview — Azure Connector Namespace models external-service connections and managed MCP server configurations. Azure Container Apps Sandboxes adds isolated sandbox deployments with configurable resource tiers and lifecycle policies, while Azure Container Apps Express offers a simplified environment option for rapid provisioning.
  • ☸️ More expressive, reliable deployments — Experimental Azure Provisioning SDK proxies let polyglot AppHosts customize infrastructure. Deployment state is isolated under ASPIRE_HOME, Kubernetes preserves inherited hostnames and embedded parameter values, and AKS gains persistent-volume provisioning and more reliable cleanup.
  • 🔌 Expanded integrations — Experimental Deno hosting and MongoDB replica sets join Foundry Toolboxes, remote Foundry Local endpoints, Blazor WebAssembly debugging, and configurable Dev Tunnel expiration. Azure Cosmos DB and AI Inference client integrations gain health checks, and the vNext Cosmos DB emulator sends its own telemetry to the dashboard.

⚠️ Breaking changes

Notable changes include automatic TLS for local MongoDB servers when a certificate is available, the Linux-based vNext Cosmos DB emulator becoming the default, new Azure Front Door origin names that can require cleanup of existing origins, portable connection-string environment-variable aliases on stricter deployment targets, and experimental terminal types moving from Aspire.Hosting.Terminals to Aspire.Hosting.ApplicationModel.

See the full list and migration guidance in the Aspire 13.6 breaking changes.

📖 Learn more

For complete details, examples, migration guidance, and everything new in this release, read What's new in Aspire 13.6.

Thank you to all the community contributors who helped make Aspire 13.6 possible! 💜

Full Changelog: v13.5.4...v13.6.0

Full commit: 56f3e9c0d216c0c7069dabb49dd0464e4827744f

Commits viewable in compare view.

Updated Aspire.Hosting.Redis from 13.5.4 to 13.6.0.

Release notes

Sourced from Aspire.Hosting.Redis's releases.

13.6.0

Aspire 13.6.0

Aspire 13.6 brings persistent application history, a refreshed and more interactive dashboard, first-party Java and Rust hosting, and new Azure deployment options. Coordinated .NET builds, portable volume paths, sharper CLI workflows, and more capable editor tooling make it easier to build, debug, and deploy applications across languages.

Highlights

  • 🗃️ Persistent, refreshed dashboard — SQLite-backed telemetry and resource snapshots let you revisit up to ten application runs, with read-only access to completed runs and default retention limits of 100,000 console log messages, structured logs, and traces each. The dashboard now ships as Native AOT and adopts Fluent UI v5 with a collapsible navigation rail.
  • 🖥️ AppHost-owned terminals and database REPLs — Experimental terminal APIs let AppHosts create interactive sessions in a dashboard dock, dialog, or separate window. Opt-in WithRepl() commands open bundled clients for PostgreSQL, MySQL, MongoDB, SQL Server, Redis, and Valkey, while aspire terminal ps and aspire terminal tape play support discovery and repeatable terminal interactions.
  • 🌐 First-party Java and Rust hosting — New Aspire.Hosting.Java and Aspire.Hosting.Rust packages bring Maven, Gradle, Spring Boot, Quarkus, and Cargo applications into the app model, with generated container builds and VS Code debugging. These integrations build on work that originated in the Aspire Community Toolkit.
  • 🛠️ More flexible AppHosts — The prerelease Aspire.Hosting.Dotnet integration coordinates compatible projects into shared restore and build groups and supports .NET SDK container publishing. Portable volume-path environment variables work across local execution and deployment, while TypeScript AppHosts gain standard appsettings.json configuration and Deno runtime support.
  • ⌨️ Sharper CLI workflows — Select launch profiles with aspire run and aspire start, update repository-local CLI manifests with aspire update, create file-based C# AppHosts with aspire init --language csharp --file-based, and export TypeScript API data with aspire sdk export. Terminal commands no longer need a feature flag, Linux certificate trust includes Firefox NSS databases, and aspire stop --force --volumes adds explicit cleanup of Aspire-owned volumes.
  • 💻 More capable VS Code tooling — Coding agents can start and stop AppHosts through the extension, and the Aspire pane exposes deploy, publish, and pipeline actions. Multi-root discovery, worktree-scoped lifecycle operations, preserved launch arguments, clearer debug logs, and missing-debugger guidance make complex workspaces more predictable.
  • ☁️ New Azure options in preview — Azure Connector Namespace models external-service connections and managed MCP server configurations. Azure Container Apps Sandboxes adds isolated sandbox deployments with configurable resource tiers and lifecycle policies, while Azure Container Apps Express offers a simplified environment option for rapid provisioning.
  • ☸️ More expressive, reliable deployments — Experimental Azure Provisioning SDK proxies let polyglot AppHosts customize infrastructure. Deployment state is isolated under ASPIRE_HOME, Kubernetes preserves inherited hostnames and embedded parameter values, and AKS gains persistent-volume provisioning and more reliable cleanup.
  • 🔌 Expanded integrations — Experimental Deno hosting and MongoDB replica sets join Foundry Toolboxes, remote Foundry Local endpoints, Blazor WebAssembly debugging, and configurable Dev Tunnel expiration. Azure Cosmos DB and AI Inference client integrations gain health checks, and the vNext Cosmos DB emulator sends its own telemetry to the dashboard.

⚠️ Breaking changes

Notable changes include automatic TLS for local MongoDB servers when a certificate is available, the Linux-based vNext Cosmos DB emulator becoming the default, new Azure Front Door origin names that can require cleanup of existing origins, portable connection-string environment-variable aliases on stricter deployment targets, and experimental terminal types moving from Aspire.Hosting.Terminals to Aspire.Hosting.ApplicationModel.

See the full list and migration guidance in the Aspire 13.6 breaking changes.

📖 Learn more

For complete details, examples, migration guidance, and everything new in this release, read What's new in Aspire 13.6.

Thank you to all the community contributors who helped make Aspire 13.6 possible! 💜

Full Changelog: v13.5.4...v13.6.0

Full commit: 56f3e9c0d216c0c7069dabb49dd0464e4827744f

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 MessagePack from 3.1.9 to 3.1.10.

Release notes

Sourced from MessagePack's releases.

3.1.10

Security fix

Other fixes

New Contributors

Full Changelog: MessagePack-CSharp/MessagePack-CSharp@v3.1.9...v3.1.10

Commits viewable in compare view.

Updated MessagePack.Annotations from 3.1.9 to 3.1.10.

Release notes

Sourced from MessagePack.Annotations's releases.

3.1.10

Security fix

Other fixes

New Contributors

Full Changelog: MessagePack-CSharp/MessagePack-CSharp@v3.1.9...v3.1.10

Commits viewable in compare view.

Updated Microsoft.Playwright.Xunit from 1.62.0 to 1.63.0.

Release notes

Sourced from Microsoft.Playwright.Xunit's releases.

1.63.0

🪟 Locate across frames

Page.FrameLocator() and Frame.FrameLocator() called without a selector search in any frame of the
subtree, so you no longer need to locate the iframe first:

// Finds the button in any frame on the page.
await Page.FrameLocator().GetByRole(AriaRole.Button).ClickAsync();

The rest of the locator resolves inside a single frame, just like a regular locator, and an error is thrown when it
matches elements in several frames.

👁️ Visible-only locators

New Locator.Visible returns a locator that matches only visible elements. It is the recommended
replacement for the :visible CSS pseudo-class:

await Page.Locator("button").Visible.ClickAsync();

🖼️ Aria and screen snapshots in traces

New AriaSnapshots and ScreenSnapshots options of Tracing.StartAsync() capture an aria snapshot and a screenshot of the page on every action:

await context.Tracing.StartAsync(new()
{
  Snapshots = true,
  AriaSnapshots = true,
  ScreenSnapshots = true
});

With aria and screen snapshots recorded, the new Display Aria mode in the trace viewer shows the action screenshot
side by side with the aria snapshot, and hovering an aria node highlights it on the screenshot.

New APIs

Browser and Context

Command line

  • pwsh bin/Debug/netX/playwright.ps1 install --no-remove keeps the browsers of other Playwright installations instead of removing them.
  • pwsh bin/Debug/netX/playwright.ps1 codegen --http-credentials records against pages behind HTTP authentication.

Announcements

... (truncated)

Commits viewable in compare view.

Updated MudBlazor from 9.10.0 to 9.11.0.

Release notes

Sourced from MudBlazor's releases.

9.11.0

[!NOTE]
The median component renders 31% less on v9.11.0 compared to v9.8.0! Read more

What's Changed

New Features

Bug Fixes

Performance

Full Changelog: MudBlazor/MudBlazor@v9.10.0...v9.11.0

Commits viewable in compare view.

Updated OpenTelemetry.Exporter.OpenTelemetryProtocol from 1.19.0 to 1.19.1.

Release notes

Sourced from OpenTelemetry.Exporter.OpenTelemetryProtocol's releases.

1.19.1

For highlights and announcements pertaining to this release see: Release Notes > 1.19.1.

The following changes are from the previous release 1.19.0.

1.19.1-rc.1

The following changes are from the previous release 1.19.0.

1.19.1-beta.1

The following changes are from the previous release 1.19.0-beta.1.

Commits viewable in compare view.

Updated OpenTelemetry.Extensions.Hosting from 1.19.0 to 1.19.1.

Release notes

Sourced from OpenTelemetry.Extensions.Hosting's releases.

1.19.1

For highlights and announcements pertaining to this release see: Release Notes > 1.19.1.

The following changes are from the previous release 1.19.0.

1.19.1-rc.1

The following changes are from the previous release 1.19.0.

1.19.1-beta.1

The following changes are from the previous release 1.19.0-beta.1.

Commits viewable in compare view.

Updated PatternKit.Core from 0.147.26 to 0.147.27.

Release notes

Sourced from PatternKit.Core's releases.

0.147.27

What's Changed

Full Changelog: JerrettDavis/PatternKit@v0.147.26...v0.147.27

Commits viewable in compare view.

Updated Quartz from 4.1.1 to 4.3.0.

Release notes

Sourced from Quartz's releases.

4.3.0

Quartz.NET 4.3 is an additive minor. Every public change is a new type, a new member on a type we own, or a default
interface member, and its schema change is one generated folder, database/migrations/4.3/, that only adds
nullable columns. A released 4.2 node and a 4.3 node share one PostgreSQL database in CI to prove a mixed cluster
runs safely. A 4.2 application upgrades by changing the version and, on a persistent store, running the 4.3 scripts
before the first 4.3 node starts. The headlines: a scheduler on a database fires one-off jobs 2.8× faster than 4.2
at its shipped defaults; a job can be a lambda; and a schedule can be steered while it runs, with an overlap policy,
a pause that says why, backfill, progress and captured logs, and a dashboard that edits. Four new packages put the job store's tables under Weasel, for applications on Marten or Wolverine.

dotnet add package Quartz --version 4.3.0

Highlights

Faster where it runs

  • A job that takes nothing from the container — no constructor parameters, not registered, no ConfigureScope —
    is built without a DI scope: 1.84 → 1.68 KB a firing on RAMJobStore, a little faster too. Every other job keeps
    its scope exactly as before. (#​3866)

  • RAMJobStore computes a cron trigger's next fire time once per firing, not twice, inside its lock. (#​3866)

  • A scheduler on a database batches what is already due, out of the box. MaxBatchSize now defaults to
    automatic: the thread pool's size on a persistent store, clustered or not, and 1 in memory.
    Nothing fires early (the fire-ahead window is still zero). On PostgreSQL a backlog of one-off jobs goes from
    about 80–91 to 125 firings a second, and from 6.0 to 2.8 commits a firing. MaxBatchSize = 1 restores 4.2.
    On a cluster, the flip was gated on a 2- and 4-node drain against a durable PostgreSQL: 1.7–2.1× faster on
    two nodes and 1.6–2.0× on four, at a lock-wait p99 of about 60 ms. One of four sittings read 0.78× on four nodes
    while every lock wait on that shared VM was slower. (#​3862, #​3900)

  • Scheduling a job costs less. ScheduleJob with a simple trigger allocates 2.76 KB, down from 3.83 KB,
    and a cron one 3.3 KB, down from 4.6 KB. Scheduling a trigger later than the one the scheduler is already
    waiting for no longer wakes it, and listener lists are built when they change, not on every call. (#​3865)

  • A firing that may run beside itself completes without the store's lock. Completions of
    concurrent-allowed jobs no longer queue behind each other on TRIGGER_ACCESS. With the batching default above,
    one-off jobs on PostgreSQL go from 4.2's 91 to 237 firings a second on the same database: 2.6×. Repeating
    triggers fire 1.5–1.9× faster. A 2- and 4-node cluster drains 1.5–1.8× faster at a fifth of the lock wait. A
    [DisallowConcurrentExecution] job, a retry, a trigger with continuations, a buffered overlap policy and a
    non-durable job's last trigger keep the lock. The misfire pass also settles a continuation whose parent no
    longer exists. (#​3863)

  • Measured on the release candidate against 4.2.0, alternating sittings on one box and one durable PostgreSQL:

    4.2.0 4.3.0
    One-off jobs on PostgreSQL, shipped defaults 90–91 a second 251–255 a second (2.8×)
    Repeating triggers on PostgreSQL at 20 a second, within ±50 ms 22 % 52 % (all within ±250 ms; worst 84–96 ms, was 205 ms)
    In-memory throughput, bytes per execution 2.81 KB 2.07 KB, and not slower
    Scheduling one simple trigger 3.4–3.6 KB 2.6–2.7 KB

    In memory every firing still lands within ±50 ms.

A job can be a lambda

... (truncated)

4.2.4

One fix, additive: no public API change and no schema change. It affects a persistent store when a database error hits one trigger of a fire batch.

Fixed

  • A database error on one trigger of a fire batch no longer commits half of it. A non-transient error while firing one trigger was recorded as that trigger's failure, and the batch committed anyway. On SQL Server and MySQL the commit kept the failed trigger's partial writes, which could leave its [DisallowConcurrentExecution] job's other triggers BLOCKED for good. On PostgreSQL the error aborted the transaction, so the commit silently rolled back triggers already reported fired: their jobs ran while the store still held them as reserved, and could run again after recovery. The failing attempt now rolls back whole, and the batch fires again without that trigger, which is reported failed. Nothing changes when nothing fails. New Warning event 3049 names the trigger. (#​3931, #​3942)

The same fix ships for 3.x in 3.22.3.

Full Changelog: quartznet/quartznet@v4.2.3...v4.2.4

4.2.3

Two fixes, both additive: no public API change and no schema change. The first affects a clustered persistent store that acquires one trigger at a time, which is 4.2's default. The second affects the cron fast path in a process that has asked about other decades.

Fixed

  • A clustered node no longer idles behind a [DisallowConcurrentExecution] job running on another node. When two nodes reserved triggers of the same such job, the node that lost released its trigger back to WAITING, though the job was still running. With one trigger acquired at a time, that trigger then sat at the head of the node's queue. It was skipped on every pass, it hid the triggers due behind it, and the node slept its whole IdleWaitTime (30 s by default). Two 4.2.2 nodes fired a once-a-second trigger 17 s late on average. A released trigger now stays BLOCKED while its job runs, and acquisition reads past a trigger it has to skip. Nothing was lost or doubled. Found by 4.3's mixed-version cluster test. (#​3926, #​3932)
  • The cron fast path answers in every year a trigger can reach, whatever the process asked about first. Its offset tables were capped at four 8-year windows per time zone. An application that had checked a calendar or an expression against other decades could leave the current window on the slow path for good, about 520 ns instead of about 37 ns a lookup. One window that failed verification also switched the whole zone off. Each window now gets its own table, built once. (#​3918, #​3932)

The acquisition fix ships for 3.x in 3.22.2. 3.x has no cron fast path.

Full Changelog: quartznet/quartznet@v4.2.2...v4.2.3

4.2.2

Three fixes, all additive: no public API change and no schema change. The first two are in the scheduler's loop and affect any scheduler on the real clock. The third affects a SQL Server store under lock contention.

Fixed

  • A trigger no longer fires after Standby() has returned. The scheduler's loop checked whether it was paused before draining its wake-up signal, so a Standby() that landed between the two, most likely while the loop was waiting for a free worker on a busy scheduler, was lost. The round then went on to acquire and fire a trigger due within the next IdleWaitTime (30 s by default). The loop now checks again after the drain. (#​3907)
  • A trigger scheduled just after another is no longer passed over, and one held in standby is let go. When two schedule calls landed before the loop read the first, the later one's time overwrote the earlier, more urgent one. That trigger then ran up to IdleWaitTime late, or went through misfire handling. The same overwrite meant Standby() followed by ScheduleJob() could fire a trigger the loop was holding. The loop now keeps the earliest pending candidate. (#​3907)
  • A row-lock handler no longer acts on a transaction SQL Server has ended. When SQL Server aborted a transaction contending for the lock row, the handler retried its lock statement inside the dead transaction. That is error 41302 with memory-optimized QRTZ_LOCKS, or a 1205 deadlock victim with the default SelectForUpdateLockHandler. SqlClient ran the retry outside any transaction, so the store acted without holding TRIGGER_ACCESS, its statements committed one by one, and the final commit failed. The handler now gives up, and the store retries the whole operation in a fresh transaction. (#​3903, #​3907)
  • A shutdown that does not wait for its jobs gives them their settle window in wall time, whatever clock the scheduler keeps. On a frozen FakeTimeProvider it used to wait forever. (#​3907)

The same scheduling and lock-handler fixes ship for 3.x in 3.22.1.

Full Changelog: quartznet/quartznet@v4.2.1...v4.2.2

4.2.1

Two fixes, both additive; no public API or schema-script change for anyone on the default SQL Server script or another database.

Fixed

  • A scheduler on a persistent store no longer waits forever to shut down on a clock nobody advances. Shutting down waits up to one second for the misfire and cluster check-in loops, and that second was measured on the scheduler's own TimeProvider. On a FakeTimeProvider that is never advanced — the usual way to test time-dependent code — a shutdown that raced the loop's start never returned. The bound is now measured in wall time. Production schedulers on the real clock were not affected; 3.x is not affected. (#​3892, backported in #​3894)

  • Execution history works on schemas created from tables_sqlServerMOT.sql or tables_sqlServer_Below2016.sql. 4.2.0 wrote RETRY_ATTEMPT and RETRY_SCHEDULED on every history row, but only tables_sqlServer.sql created them, so with execution history on every history write failed with Invalid column name 'RETRY_ATTEMPT'. Both scripts now create them. (#​3894) An existing schema created from either script adds them with (safe to run twice):

    IF COL_LENGTH('dbo.QRTZ_EXECUTION_HISTORY', 'RETRY_ATTEMPT') IS NULL
    ALTER TABLE [dbo].[QRTZ_EXECUTION_HISTORY] ADD [RETRY_ATTEMPT] int NOT NULL DEFAULT 0;
IF COL_LENGTH('dbo.QRTZ_EXECUTION_HISTORY', 'RETRY_SCHEDULED') IS NULL
    ALTER TABLE [dbo].[QRTZ_EXECUTION_HISTORY] ADD [RETRY_SCHEDULED] bit NOT NULL DEFAULT 0;

    Schemas from tables_sqlServer.sql, from database/migrations/4.2/add_execution_history_sqlServer.sql, or from SchemaProvisioning.CreateIfMissing already have them.

Full Changelog: quartznet/quartznet@v4.2.0...v4.2.1

4.2.0

Quartz.NET 4.2 is an additive minor: every public change is a new type, a new member on a type we own, or a default interface member, and its one schema change is a generated migration under database/migrations/4.2/ that a mixed 4.1/4.2 cluster runs safely. A 4.0 or 4.1 application upgrades by changing the version and, on a persistent store, running that migration before the first 4.2 node starts. The headline is that a job can be declared on its class — [QuartzJob] and [CronTrigger] — with the cron expression checked by the compiler, and that one trigger can wait, in the store, for another's outcome.

dotnet add package Quartz --version 4.2.0

Highlights

  • A cron or timeout literal that cannot parse is a build error. Quartz.nupkg now carries an analyzer under analyzers/dotnet/cs: QZ0001 refuses a cron literal the parser would refuse — at WithCronSchedule, CronScheduleBuilder.Create, the CronExpression constructors and parse members, CronCalendar and CronTriggerImpl, honouring a literal CronFormat.Unix — with the parser's own message; QZ0002 refuses a [JobTimeout("…")] that does not parse or is negative; QZ0003 warns on [PersistJobDataAfterExecution] without [DisallowConcurrentExecution]; QZ0004 (Info) notes an Execute that never observes its cancellation token. The analyzer is netstandard2.0 and links the cron parser's own sources rather than a second grammar, so a literal the compiler accepts is one the scheduler accepts; a parity corpus of 128 expressions pins that. <DisableQuartzAnalyzers>true</DisableQuartzAnalyzers> in the project file turns it off (#​3846) — ExcludeAssets="analyzers" does not, on the .NET 10 SDK; the package's dependencies are unchanged. (#​3803, #​3815)
  • A job declares itself on its class, and the compiler writes the registration. [QuartzJob(Name, Group, Description, Durable, RequestRecovery, Scheduler)] on an IJob and one [CronTrigger("…", Name, Group, TimeZone, MisfireInstruction, Priority, Description, ExecutionGroup)] per schedule are read by a source generator inside Quartz.nupkg, which writes an AddDeclaredJobs() extension for IQuartzBuilder calling the same AddJob<T>/AddTrigger<T> you would have written — no reflection, nothing to root for trimming, and the cron expression checked at compile time by QZ0001. QZ1001–QZ1003 refuse an attribute on a type that is not a concrete IJob, two declarations with one identity, and a [CronTrigger] without [QuartzJob]. Scheduler = "…" binds a declaration to one named scheduler. [SimpleTrigger] and a cron read from configuration are the deliberate follow-ups. (#​3804, #​3818)
  • A trigger can wait, in the store, for another trigger's outcome. TriggerBuilder.StartAfter(parentKey, condition) — or scheduler.ScheduleJob<TJob,TInput>(input, Continuation.After(parentKey), …) for a one-off — stores a trigger in the new state Awaiting; when the parent's firing ends, its completion settles every continuation inside its own transaction, on whichever node ran it: a matching outcome (OnSuccess, OnFailure, OnCancellation, OnVeto, or OnAnyOutcome) releases the trigger to fire now, any other discards it, and a scheduled retry settles nothing. A parent deleted while continuations wait releases the OnAnyOutcome ones and parks the rest in Error. Every store call that completes a firing now carries ExecutionOutcome and the exception through TriggeredJobCompleteContext. JobChainingJobListener keeps the recurring case and gains a condition. A continuation can be declared in quartz_jobs.xml (<continues-after>, <continuation-condition>), in quartz_jobs.json and the Quartz:Schedule section (ContinuesAfter, ContinuationCondition), scheduled over the wire, and seen in the dashboard — an Awaiting filter on Triggers, and "Continues after" and "When" on a trigger's detail. Job Continuations is the page. (#​3805, #​3806, #​3819, #​3821)
  • A retry policy that gives up says so. IJobExecutionContext.Outcome and RetryScheduled tell a listener what the job did and whether a retry follows; ITriggerListener.TriggerRetriesExhausted is raised once when a policy runs out (a default interface member, so no listener needs to change); the counter quartz.trigger.retries_exhausted counts it; execution history records the attempt and whether a retry was scheduled, the History page and the history routes filter on "failed after retries", and a final failure on the History page has a Run again button, recorded in the Action Log. RetryPolicy.Exponential takes an optional jitter that spreads the attempts. One correction rides along: IJobExecutionContext.RetryAttempt now reports the attempt the firing is to listeners as well — it used to read the trigger's field after ExecutionComplete had already advanced or cleared it. (#​3807, #​3829)
  • A cron expression's next occurrence is eleven times faster and asks the time zone nothing on the steady-state path. GetNextValidTimeAfter used to make eight TimeZoneInfo queries per answer; it now walks the expression's own bitmasks on the wall clock and resolves the offset through a per-zone table of safe segments — intervals verified against the zone's own answers, with everything within 48 hours of a transition, and every zone the table cannot verify, left to the existing code. Every DST edge case still runs the code that handled it before, and a differential test compares the two paths to the tick across ten zones, half of its instants near transitions. On the machine the benchmark README names: 0 0/5 * * * ? 421 → 36.5 ns and 100 successive occurrences 43.1 → 3.5 µs, zero allocations, against NCrontab's 25.3 ns and 2.7 µs; the second-level form now beats NCrontab. The one cost is 8 bytes on each CronExpression. (#​3801, #​3820)
  • Quartz is measured against the schedulers it is compared to, and the numbers are published. src/Quartz.Benchmark.Competitors/ runs the same five workloads against TickerQ 10.4.0 and Hangfire 1.8.25 — firing throughput in memory and on PostgreSQL, schedule-to-execute latency, punctuality of one-second schedules, and the cost of one schedule call — with completion counted inside the executing job on every side, and the benchmark README and the operations page carry the tables, the rows Quartz loses included. On the box the README names, Quartz at its defaults executes 181,000–257,000 in-memory one-offs a second (TickerQ 98,000–115,000, Hangfire 58,000–92,000), reaches Execute 58–70 µs after ScheduleJob (TickerQ 14.7 ms, Hangfire 94–235 µs), and fires 100 % of one-second schedules within 50 ms (TickerQ 73–78 %, Hangfire 0–15 %); a schedule call costs 7.7–10 µs against TickerQ's 1.1–2.4 µs, and on PostgreSQL a one-off firing makes too many round trips — which #​3824 addresses. The profiling switches that found where the time goes (--profile-fire, --profile-cron, --profile-schedule, --latency) ship in Quartz.Benchmark, and out-of-process benchmark runs work again. On RAMJobStore a firing now allocates 1.83 KB where 4.1 allocated 2.63 KB and dispatches with two fewer thread hand-offs — an empty job data map costs nothing to clone or build, one task per dispatch instead of three, one ambient slot per firing, the run shell handed to the pool as state (IThreadPool.TryRunWithState, a default interface member), the firing's clock read only when a span is listening — 12–14 % faster on the fire-throughput benchmark. And one durable job with thousands of triggers behind it — the one-off API's own shape — no longer costs the store a linear scan and an array of keys on every completion: churn against a job with 20,000 triggers went from 183 µs and 157 KB to 434 ns and 424 B. (#​3802, #​3816, #​3822, #​3823, #​3826)
  • Execution history can live in the database, and the store keeps it trimmed. UsePersistentStore(s => s.UseExecutionHistory()) — or quartz.jobStore.executionHistory = true — records every execution and misfire into QRTZ_EXECUTION_HISTORY and QRTZ_MISFIRE_HISTORY in the scheduler's own database, so a cluster has one history and every node's dashboard, the HTTP API's history routes and a store-attached window read the same rows. Retention is the store's: a sweep on the scheduler's clock deletes past ExecutionHistoryOptions.Retention and trims to MaxEntriesPerScheduler, idempotently, so several nodes sweeping at once is harmless. Writes go on their own connection, never inside a job's transaction, and a failed write is logged and dropped rather than failing the firing. The tables are optional: a 4.2 node validates them only when the history is on, and names the script when they are missing. (#​3771, #​3825)
  • The dashboard can be pointed at a database and show every scheduler in it. AddQuartzDashboard(o => o.AttachStore("prod", store => store.UseSqlServer(cs))) discovers the schedulers a database holds and opens a window on each — a never-started scheduler over the shared store, listed with the new origin Window and the target's name, its status derived from the cluster's check-in rows rather than from itself (no rows reads as unknown, not as stopped), with every scheduling action available and the node-local ones — start, stand-by, shutdown, interrupt — hidden with a sentence saying they need an API or agent target. With the database-backed history store the window's History page shows what the nodes ran. This is the shared-storage reach model a cluster behind a load balancer needs, with zero worker changes and no inbound port; the docs say what a window can and cannot do and that it needs the cluster's serializer configuration. (#​3772, #​3828)
  • The documentation compares, and says where Quartz loses. A comparison page puts Quartz.NET beside Hangfire 1.8.25, TickerQ 10.4.0, Wolverine 6.35 and Coravel 6.0, one sourced table per concern, with a section collecting the places Quartz is the more expensive answer; two guides map Hangfire's and TickerQ's APIs to ours and name the differences that bite (six cron fields and a different default time zone, [Queue] → execution groups that bound but do not route, retries held in the store rather than the worker, a dashboard that refuses to start until told who may reach it). The best-practices page no longer says Quartz has no retry policy, the quick start leads with the three-line form, and the index says what nobody knew was in the box. (#​3808, #​3813, #​3814)
  • The health check can say a scheduler has stopped firing. QuartzHealthCheckOptions.StaleFiringTolerance (off unless set; 3 is the documented starting value) asks the store for a schedulable trigger whose fire time passed more than that many misfire thresholds ago and reports Degraded, or Unhealthy past twice the bar — the silent stall that "running" and "store answers" never caught, with the overdue trigger, when it was due and by how much in the report's data. The worse of the check-in and stalled-firing verdicts now wins, where a late check-in used to hide a stall. Underneath, TriggerQuery.NextFireTimeBefore is a new filter every store and the HTTP API honour. (#​3809, #​3817)

Public API — additive only

Added What it is
[QuartzJob], [CronTrigger] the attributes the source generator reads; AddDeclaredJobs() is generated into your assembly
Continuation, ContinuationCondition, ExecutionOutcome, TriggeredJobCompleteContext, AwaitingContinuation a continuation, the outcomes that release it, what a firing did, and the context a store's completion receives
ITrigger.Continuation, ITriggerConfigurator<TJob>.StartAfter — default interface members; TriggerBuilder<TJob>.StartAfter; ScheduleJob<TJob, TInput>(input, Continuation after, options); JobChainingJobListener.AddJobChainLink(first, second, condition) and JobExecutionVetoed declaring a continuation, in the builder, in the one-off call, or on the recurring listener
IJobStore.FiringComplete(TriggeredJobCompleteContext) — DIM; IDriverDelegate.SelectAwaitingContinuations, ReleaseContinuation, ResetContinuationFireTime, SelectSchedulerNames — DIMs what a store and a dialect implement to settle continuations and to be discovered by a window; a store from outside this repository keeps working unchanged
TriggerState.Awaiting, StoredTriggerState.Awaiting; TriggerHeader.ContinuesAfter, ContinuationCondition; TriggerQuery.NextFireTimeBefore; the AdoConstants names of the new columns, tables and state the state on the wire and in the store, and the two new query filters
IJobExecutionContext.Outcome, RetryScheduled; ITriggerListener.TriggerRetriesExhausted — DIMs; ExecutionHistoryEntry.RetryAttempt, RetryScheduled; ExecutionHistoryQuery.FailedFinally; RetryPolicy.Exponential(…, jitter) and RetryPolicy.Jitter; the meter quartz.trigger.retries_exhausted the retry signal, end to end
IPersistentStoreBuilder.UseExecutionHistory() — DIM; AdoJobStoreOptions.ExecutionHistory history in the database
SchedulerOrigin.Window; SchedulerRegistration.Target; QuartzDashboardOptions.AttachStore, AttachStoreOptions; SchedulerHeaderDto.Target, IsWindow, DisplayName store-attached targets
QuartzHealthCheckOptions.StaleFiringTolerance the stalled-firing reading
IThreadPool.TryRunWithState — DIM the pool dispatch that carries state instead of a closure
ObjectDoesNotExistException what scheduling a continuation of a trigger the store does not hold throws, naming both keys; it round-trips over ...

_Description h...

Description has been truncated

@dependabot
chore(deps): Bump the nuget-dependencies group with 15 updates
19b616e 
Bumps Aspire.Hosting.PostgreSQL from 13.5.4 to 13.6.0
Bumps Aspire.Hosting.Redis from 13.5.4 to 13.6.0
Bumps coverlet.collector from 10.0.1 to 10.1.0
Bumps MessagePack from 3.1.9 to 3.1.10
Bumps MessagePack.Annotations from 3.1.9 to 3.1.10
Bumps Microsoft.Playwright.Xunit from 1.62.0 to 1.63.0
Bumps MudBlazor from 9.10.0 to 9.11.0
Bumps OpenTelemetry.Exporter.OpenTelemetryProtocol from 1.19.0 to 1.19.1
Bumps OpenTelemetry.Extensions.Hosting from 1.19.0 to 1.19.1
Bumps PatternKit.Core from 0.147.26 to 0.147.27
Bumps Quartz from 4.1.1 to 4.3.0
Bumps Quartz.AspNetCore from 4.1.1 to 4.3.0
Bumps TinyBDD from 0.19.40 to 0.19.43
Bumps TinyBDD.Xunit from 0.19.40 to 0.19.43
Bumps WireMock.Net from 2.16.0 to 2.18.0

---
updated-dependencies:
- dependency-name: Aspire.Hosting.PostgreSQL
  dependency-version: 13.6.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: Aspire.Hosting.Redis
  dependency-version: 13.6.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: coverlet.collector
  dependency-version: 10.1.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: MessagePack
  dependency-version: 3.1.10
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: MessagePack.Annotations
  dependency-version: 3.1.10
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: Microsoft.Playwright.Xunit
  dependency-version: 1.63.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: MudBlazor
  dependency-version: 9.11.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: OpenTelemetry.Exporter.OpenTelemetryProtocol
  dependency-version: 1.19.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: OpenTelemetry.Extensions.Hosting
  dependency-version: 1.19.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: PatternKit.Core
  dependency-version: 0.147.27
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: Quartz
  dependency-version: 4.3.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: Quartz.AspNetCore
  dependency-version: 4.3.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: TinyBDD
  dependency-version: 0.19.43
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: TinyBDD.Xunit
  dependency-version: 0.19.43
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: WireMock.Net
  dependency-version: 2.18.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot mentioned this pull request Oct 5, 2026
Closed
@JerrettDavis
JerrettDavis merged commit 4ac34a1 into master Oct 9, 2026
13 checks passed
@dependabot
dependabot Bot deleted the dependabot/nuget/nuget-dependencies-7234630c35 branch October 9, 2026 03:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@JerrettDavis