Skip to content

Update all non-major dependencies - #53

Open
renovate[bot] wants to merge 2 commits into
masterfrom
renovate/all-non-major-dependencies
Open

Update all non-major dependencies#53
renovate[bot] wants to merge 2 commits into
masterfrom
renovate/all-non-major-dependencies

Conversation

@renovate

@renovate renovate Bot commented Sep 15, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence Type Update Pending
@react-router/dev (source) 8.3.1 → 8.4.0 age confidence devDependencies minor
@react-router/node (source) 8.3.1 → 8.4.0 age confidence dependencies minor
@react-router/serve (source) 8.3.1 → 8.4.0 age confidence dependencies minor
@types/node (source) 25.9.5 → 25.9.9 age confidence devDependencies patch
@types/react (source) 19.2.18 → 19.3.0 age confidence devDependencies minor
@types/react-dom (source) 19.2.5 → 19.3.0 age confidence devDependencies minor
Aspire.AppHost.Sdk 13.5.3 → 13.6.0 age confidence msbuild-sdk minor 13.6.1
Aspire.Hosting.AppHost 13.5.3 → 13.6.0 age confidence nuget minor 13.6.1
Aspire.Hosting.JavaScript 13.5.3 → 13.6.0 age confidence nuget minor 13.6.1
Aspire.Hosting.Testing 13.5.3 → 13.6.0 age confidence nuget minor 13.6.1
Microsoft.AspNetCore.Authentication.OpenIdConnect (source) 10.0.11 → 10.0.12 age confidence nuget patch
Microsoft.Extensions.Hosting.Systemd (source) 10.0.11 → 10.0.12 age confidence nuget patch
Microsoft.NET.Test.Sdk 18.9.0 → 18.10.1 age confidence nuget minor
Microsoft.Playwright 1.62.0 → 1.63.0 age confidence nuget minor
OpenIddict.Server.AspNetCore (source) 7.6.1 → 7.7.1 age confidence nuget minor
Polly 8.7.0 → 8.8.0 age confidence nuget minor
Quartz (source) 3.20.0 → 3.22.3 age confidence nuget minor 3.22.4
Quartz.Extensions.DependencyInjection (source) 3.20.0 → 3.22.3 age confidence nuget minor 3.22.4
Quartz.Extensions.Hosting (source) 3.20.0 → 3.22.3 age confidence nuget minor 3.22.4
coverlet.collector 10.0.1 → 10.1.0 age confidence nuget minor
dotnet-sdk 10.0.400 → 10.0.401 age confidence dotnet-sdk patch
react (source) 19.2.8 → 19.3.0 age confidence dependencies minor
react-dom (source) 19.2.8 → 19.3.0 age confidence dependencies minor
react-router (source) 8.3.1 → 8.4.0 age confidence dependencies minor
vite (source) 8.2.2 → 8.3.2 age confidence devDependencies minor 8.3.4 (+1)

Release Notes

remix-run/react-router (@​react-router/dev)

v8.4.0

Compare Source

Patch Changes
  • Fix action submissions behind an HTTPS reverse proxy in react-router dev and vite preview by using X-Forwarded-Proto when constructing request.url (#​15466)
    • No React Router configuration is required
    • The URL host continues to come from Host, not X-Forwarded-Host
    • Configure reverse proxies to overwrite client-supplied X-Forwarded-Proto headers
    • Do not expose dev or preview servers publicly
  • Pass development conditions as CLI flags when relaunching the dev process (#​15435)
  • Fix stack trace locations for split route modules when source maps are enabled in the reactRouter Vite plugin (#​15440)
  • Updated dependencies:
remix-run/react-router (@​react-router/node)

v8.4.0

Compare Source

Patch Changes
  • Fix a memory leak in writeReadableStreamToWritable and writeAsyncIterableToWritable that retained memory for the lifetime of a long-running stream (#​15500)
    • Preserve error handling when a producer closes the destination while reading the next chunk
  • Updated dependencies:
remix-run/react-router (@​react-router/serve)

v8.4.0

Compare Source

Patch Changes
microsoft/aspire (Aspire.AppHost.Sdk)

v13.6.0: Aspire 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

v13.5.4: Aspire 13.5.4

What's New in Aspire 13.5.4

Patch release for Aspire 13.5 that fixes Kafka health-check resource leaks, DevTunnel errors with automatically selected regions, misleading Azure emulator dashboard entries, and unintended changes to generated starter apps, plus Homebrew compatibility and Radius API diagnostic updates.

🐛 Fixes

  • 📨 Kafka health checks leaked producers and polling threads — Each AppHost health-check execution created a new Kafka producer without disposing it, accumulating background threads over time. Health checks now reuse a producer per Kafka resource and dispose it with the AppHost, while keeping multiple Kafka resources independently configured. Fixes #​20091. (#​20094, backport of #​20092, @​davidfowl)

  • 🌐 DevTunnels could fail when the region was selected automatically — Tunnel setup and health checks now use the cluster-qualified tunnel ID returned by the DevTunnel CLI for port operations and access queries. This fixes failures when a bare tunnel ID cannot be resolved for those operations. Regression introduced in 13.3. Fixes #​18790. (#​19853, backport of #​19230, @​Vladipz)

  • ☁️ Emulator-only AppHosts showed an unused Azure environment — The dashboard now hides the azure-environment resource when no Azure resources require cloud provisioning, instead of leaving it visible in Not started. It remains visible for apps that combine local emulators with resources requiring Azure provisioning. No AppHost changes are needed. Fixes #​19617. (#​19998, backport of #​19843, @​eerhardt)

  • 🧩 Starter app generation could alter unrelated JavaScript values — Dynamic port replacement could also replace matching numeric literals in bundled JavaScript, including Bootstrap timing values. Port substitutions are now restricted to localhost: URLs, preserving the original library files while still configuring the requested ports. Fixes #​20030. (#​20110, backport of #​20031, @​bart-vmware, @​JamesNK)

  • 🍎 Updated the Aspire Homebrew cask for Homebrew 6.x — Replaced deprecated cask URL and post-install syntax with the supported equivalents, resolving compatibility issues with current Homebrew while preserving install-channel metadata. (#​20119, backport of #​19965, @​askpt, @​joperezr)

  • 🧪 Radius cloud-provider callback interfaces now carry the experimental diagnostic — IAwsRadiusProviderBuilder and IAzureRadiusProviderBuilder are now marked with ASPIRERADIUS003, matching the existing WithAwsProvider and WithAzureProvider methods. Code referencing these interfaces directly must now acknowledge the same experimental API diagnostic. (#​19874, @​sebastienros)

Full Changelog: v13.5.3...v13.5.4

Full commit: 9c1b401dd67746739044f68959cbf4d3d7af93a6

dotnet/dotnet (Microsoft.AspNetCore.Authentication.OpenIdConnect)

v10.0.12

microsoft/vstest (Microsoft.NET.Test.Sdk)

v18.10.1

What's Changed

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

v18.10.0

What's Changed

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

microsoft/playwright-dotnet (Microsoft.Playwright)

v1.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

  • ⚠️ Ubuntu 20.04 is not supported anymore.
  • 🐧 On Linux arm64, Playwright now downloads the Chrome for Testing build of Chromium, the same build used on all other platforms.

Browser Versions

  • Chromium 153.0.8010.12
  • Mozilla Firefox 155.0
  • WebKit 26.6

This version was also tested against the following stable channels:

  • Google Chrome 153
  • Microsoft Edge 153
openiddict/openiddict-core (OpenIddict.Server.AspNetCore)

v7.7.1

Compare Source

This release introduces the following changes:

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

v7.7.0

Compare Source

This release introduces the following changes:

  • A vulnerability affecting the validation of audiences contained in client assertions by the OpenIddict server stack was identified earlier today (thanks @​x-redacted! ❤️) and fixed.

[!CAUTION]
Upgrading to OpenIddict 7.7 or 8.0 preview 4 is strongly advised. See GHSA-925x-4h4v-2792 for more information.

[!IMPORTANT]
On .NET Framework and .NET Standard 2.0/2.1, the package keeps referencing the 3.x branch, as Quartz.NET 4.0 is only compatible with .NET 10 and higher.

  • The aud claim in client assertions can now be represented as a JSON array, as allowed by the recent versions of the Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants specification.

  • The OpenIddict.Client.WebIntegration package now supports JoinRpg (thanks @​leotsarev! ❤️)

  • grant_type=urn:ietf:params:oauth:grant-type:device_code token requests that don't include a client identifier are now rejected earlier by the OpenIddict server stack.

  • The net9.0-android, net9.0-ios, net9.0-maccatalyst and net9.0-macos target framework monikers are no longer supported by Microsoft and have been removed from the OpenIddict.Client.SystemIntegration package and the OpenIddict metapackage. Users of the OpenIddict.Client.SystemIntegration package are invited to migrate to .NET 10.0.

  • All the .NET and third-party dependencies have been updated to their latest version.

  • The System.Interactive.Async dependency (used only on .NET Framework and .NET Standard) was downgraded to 3.2.0 to fix a TypeLoadException that prevented using the OpenIddict Entity Framework Core 2.3 stores on .NET Framework after migrating to OpenIddict 7.6.0.

App-vNext/Polly (Polly)

v8.8.0

Compare Source

quartznet/quartznet (Quartz)

v3.22.3

One fix for the 3.x line, additive: no public API change and no schema change. It is a port of a fix found while building Quartz.NET 4.3.

Fixed
  • A database error on one trigger of a fire batch no longer commits half of it. JobStoreSupport.TriggersFired recorded a non-transient error while firing one trigger as that trigger's failure, and committed the batch 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. (#​3931, #​3944)

The same fix ships for 4.2 in 4.2.4.

Full Changelog: quartznet/quartznet@v3.22.2...v3.22.3

v3.22.2

One fix for the 3.x line, additive: no public API change and no schema change. It is a port of a fix found while building Quartz.NET 4.3.

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, which is 3.x's default, 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). JobStoreSupport now keeps a released trigger BLOCKED while its job runs, and acquisition reads past a trigger it has to skip. Nothing was lost or doubled. (#​3926, #​3936)

The same fix ships for 4.2 in 4.2.3.

Full Changelog: quartznet/quartznet@v3.22.1...v3.22.2

v3.22.1

Four fixes for the 3.x line, all additive: no public API change and no schema change. They are ports of fixes found while building Quartz.NET 4.3, plus one found while proving them.

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 fire a trigger due within the next IdleWaitTime (30 s by default). (#​3908)
  • 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. (#​3908)
  • A row-lock semaphore no longer acts on a transaction SQL Server has ended. When SQL Server aborted a transaction contending for the lock row, the semaphore retried its lock statement inside the dead transaction: error 41302 with memory-optimized locks, or a 1205 deadlock victim. SqlClient ran the retry outside any transaction, so the store acted without holding TRIGGER_ACCESS. UpdateLockRowSemaphore, UpdateLockRowSemaphoreMOT and StdRowLockSemaphore now give up, and JobStoreSupport retries the operation in a fresh transaction. (#​3908)
  • DirectSchedulerFactory.CreateScheduler returns a scheduler whose job store has finished initializing. It started the store's Initialize without waiting for it. A call made before Start() could then run while the store was still probing its optional columns, and fail reading a trigger (IndexOutOfRangeException: MISFIRE_ORIG_FIRE_TIME). A store that fails to initialize now fails CreateScheduler instead of leaving a broken scheduler registered. (#​3908)

Full Changelog: quartznet/quartznet@v3.22.0...v3.22.1

v3.22.0

Quartz.NET 3.22.0 carries three fixes to the persistent store's recovery and clustering paths, each found on the 4.0 line and ported here. One of them adds a setting the store never had — a timeout on the statements it issues — which is the public-surface addition that makes this a minor rather than a patch. The schema is 3.20's. Two of the changes alter behaviour, each marked Behavior change worth noting below.

dotnet add package Quartz --version 3.22.0

What changed

  • A job that requested recovery is recovered after a hard kill when the application declares its jobs and triggers through AddJob/AddTrigger and the store already holds them. The declared trigger was applied as a reschedule, which went through ReplaceTrigger and deleted every fired-trigger row of the key — before Start(), so by the time the first cluster check-in or the non-clustered sweep looked for the interrupted execution, its row was gone. A replacement is not a removal: ReplaceTrigger now deletes the trigger row only, and unscheduling still takes the fired rows with it. The replacement of a trigger whose job disallows concurrent execution is stored BLOCKED behind an execution still in flight, as any trigger of that job is, where it used to be stored WAITING and could fire alongside. A fast restart under a stable instance id had a second defect: on its first check-in a node handed its own state row to recovery, and the deferral grace period judged that row by its old timestamp, so the EXECUTING row of a serial job was preserved for a second detection that never came — the node's own record is never deferred now. (#​3759, port of e60bd26)
    • Behavior change worth noting: replacing a trigger keeps its fired-trigger rows, and the replacement of a non-concurrent job's trigger is stored BLOCKED while an execution is in flight.
  • quartz.jobStore.commandTimeout bounds every statement the store issues, the lock statement included. A row lock belongs to the database session that took it, so a node that loses its network without the server noticing keeps TRIGGER_ACCESS locked, and every other node's next lock statement queues behind that dead session — and nothing on this branch bounded the wait: the statement never failed, so the lock handler's retries, DbRetryInterval back-off and the SchedulerError notification never ran, and the cluster stopped firing without logging anything (#​3763). The setting is a millisecond count like every other duration on the store; 0 means the provider's own default (30 seconds for most), a negative value is refused where it is configured, and a value past what ADO.NET can hold in whole seconds is refused for the same reason. It is rounded up to whole seconds, because rounding down would turn a sub-second value into "wait forever". It reaches the driver delegate through DelegateInitializationArgs and the lock handler through DBSemaphore.CommandTimeout, which the store writes once its handler is known — so a handler named by quartz.jobStore.lockHandler.type is bounded too. An unconfigured store imposes nothing. SchedulerBuilder's persistent-store options set it fluently. The troubleshooting page gains the dead-session case: how to tell it apart in each database, why killing a process does not reproduce it, and the server-side settings that are the only thing that frees the lock. 4.x has the same setting as JobStore:CommandTimeout. (#​3764, #​3765)
  • A failed check-in is retried inside the window its peers give it. A peer writes a node off once interval + threshold has passed since the row it last wrote — 15 s on the defaults — and the cluster manager's sleep after a failed check-in was floored at DbRetryInterval, also 15 s, so a check-in that failed at 7.5 s was next attempted after the peers had already recovered the node: its fired-trigger rows deleted, its recovering jobs fired again, [DisallowConcurrentExecution] no longer holding. Java Quartz sleeps the same way, so this is inherited rather than a regression. While the window is still open a failed check-in is now retried inside it — half of what is left each time, never later than DbRetryInterval, never sooner than the loop's pause — and only once it has closed does the ordinary back-off apply. The manager times the window from its own record of the last check-in that reached the database, not from the store's LastCheckin, which a failed read also stamps. Defaults and the 15-second failover latency are unchanged, and threshold >= DbRetryInterval is no longer a relation an operator has to know about. The configuration reference's clusterCheckinInterval default (7500, not 15000) and the missing clusterCheckinMisfireThreshold row were fixed on the way. (port of a5b2197)
    • Behavior change worth noting: after a failed check-in the next attempt comes sooner than DbRetryInterval while the peers' window is still open.

Public API — additive only

  • JobStoreSupport.CommandTimeout, DBSemaphore.CommandTimeout, AdoUtil.CommandTimeout, DelegateInitializationArgs.CommandTimeout, SchedulerBuilder.PersistentStoreOptions.CommandTimeout — the one setting, wherever a statement is prepared.

Upgrading

dotnet add package Quartz --version 3.22.0. Nothing to migrate; the schema is unchanged. The 4.x line is the current major and carries all three fixes as well; the 4.x migration guide is the way there.

Full changelog: quartznet/quartznet@v3.21.0...v3.22.0

v3.21.0

Quartz.NET 3.21.0 carries the three fixes held back from 3.20.1 because each needed a small addition to the public surface or changed what a running scheduler does. All three were found while 4.0 was being finished; each is as old as 3.x. The public API grows by two interfaces on one class and nothing else; the schema is 3.20's. Three of the changes alter behaviour, each marked Behavior change worth noting below.

dotnet add package Quartz --version 3.21.0

What changed

  • ResumeAll clears every paused trigger group, not only the ones with triggers — the persistent store resumed the groups it found in QRTZ_TRIGGERS and then deleted only its all-groups marker, so a group paused while it held no triggers kept its QRTZ_PAUSED_TRIGGER_GRPS row and went on pausing whatever was scheduled into it afterwards. Pausing a group before anything is scheduled into it is a documented use of the exact-name matcher, so this was a row the store wrote on purpose and could not take back. The trailing delete now takes every group, as RAMJobStore has always done. (#​3721, #​3742, port of f76b04a)
    • Behavior change worth noting: a group paused while empty no longer survives ResumeAll.
  • A job store closes its lock handler when it shuts down — RedisSemaphore opened a ConnectionMultiplexer on the first lock and kept it, with its heartbeat, for the life of the process, because nothing on the store's shutdown path reached the lock handler and ISemaphore had no member that meant "we are done". On a branch that targets netstandard2.0 and net462 an interface cannot gain a default member, so JobStoreSupport.Shutdown now disposes a lock handler that implements IAsyncDisposable or IDisposable, after the misfire handler, the cluster manager and the connection manager have stopped, logging and continuing if that throws; RedisSemaphore implements both and closes the multiplexer it opened. (#​3721, #​3742, port of #​3639)
    • Behavior change worth noting: a custom ISemaphore that implements either interface is now disposed at shutdown.
  • A configured wait longer than the platform's timer ceiling is refused where it is set — Task.Delay refuses anything longer than about 49.7 days on .NET and about 24.9 days on .NET Framework, with an ArgumentOutOfRangeException naming a parameter called delay, and every duration Quartz waits out that way was accepted unchecked and reported later from wherever the wait happened. MisfireHandlerFrequency, MisfireThreshold (when it is also the handler's sleep), ClusterCheckinInterval, DbRetryInterval, TransientRetryInterval, the row-lock handlers' RetryPeriod, StartDelayed's argument and QuartzHostedServiceOptions.StartDelay now name the setting, the ceiling and the value at configuration time. The ceiling is per target framework, held to what Task.Delay actually accepts by a test. (#​3721, #​3742, port of #​3577)
    • Behavior change worth noting: a value past the ceiling now fails at configuration rather than later.

Public API — additive only

  • Quartz.Extensions.Redis: RedisSemaphore implements IAsyncDisposable and IDisposable.

Upgrading

dotnet add package Quartz --version 3.21.0. Nothing to migrate. The 4.0 line is the current major; the 4.x migration guide is the way there, and 4.0.1 made the upgrade one a dependency bot can offer.

Full changelog: quartznet/quartznet@v3.20.1...v3.21.0

v3.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 d

❗ Important

✂ PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • Between 12:00 AM and 06:59 AM, only on Tuesday (* 0-6 * * 2)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the automation label Sep 15, 2026
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 8 times, most recently from 2e1355c to f0f2fa4 Compare September 20, 2026 22:46
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 5 times, most recently from 778b142 to 0c096fc Compare September 29, 2026 18:29
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch 9 times, most recently from 79c9e61 to 8a9005a Compare October 6, 2026 14:47
@renovate
renovate Bot force-pushed the renovate/all-non-major-dependencies branch from 99023ff to 0bcaab3 Compare October 7, 2026 02:27
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

automation

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants