Skip to content

chore(deps): Bump the nuget-dependencies group with 11 updates - #48

Open
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/nuget/nuget-dependencies-ad639f3869
Open

chore(deps): Bump the nuget-dependencies group with 11 updates#48
dependabot[bot] wants to merge 1 commit into
masterfrom
dependabot/nuget/nuget-dependencies-ad639f3869

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 28, 2026

Copy link
Copy Markdown
Contributor

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

Release notes

Sourced from Quartz's releases.

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 the HTTP API

Nothing was removed or reshaped. Baseline diff v4.1.1..v4.2.0: Quartz 111 added member lines, 0 removed, twelve of them default interface members; Quartz.Dashboard 12 added, 0 removed (24 lines re-ordered by the generator); Quartz.AspNetCore and Quartz.HttpClient unchanged. The Quartz package now depends on nothing new and carries analyzers/dotnet/cs/Quartz.Analyzers.dll and buildTransitive/net10.0/Quartz.targets, which reads DisableQuartzAnalyzers.

Schema

database/migrations/4.2/add_continuations_<dialect>.sql adds CONTINUES_TRIGGER_NAME, CONTINUES_TRIGGER_GROUP and CONTINUATION_CONDITION to QRTZ_TRIGGERS, nullable. Required from 4.2.0: a 4.2 node refuses to start against a database without them, naming the script. Safe to apply while 4.0 and 4.1 nodes run — they never read the columns — but a 4.1 node cannot settle a continuation, so migrate, roll every node, then start scheduling them. 4.2/add_execution_history_<dialect>.sql adds QRTZ_EXECUTION_HISTORY and QRTZ_MISFIRE_HISTORY, optional: needed only with UseExecutionHistory(); a fresh install and ProvisionSchema() create them regardless.

Behaviour changes worth noting

  • TriggerState.Awaiting is a new value on the wire; a 4.1 Quartz.HttpClient reading a 4.2 host that has continuations sees a state it does not know — upgrade the client. A store outside this repository that overrides TriggeredJobComplete keeps working (FiringComplete forwards to it) and settles no continuations until it implements the new member.
  • Quartz.nupkg carries an analyzer. A project whose cron or timeout literals were wrong builds no longer — that is the point — and a build with TreatWarningsAsErrors sees QZ0003 as an error; <DisableQuartzAnalyzers>true</DisableQuartzAnalyzers> opts out, .editorconfig re-tunes a severity.
  • A continuation needs its parent to exist when it is scheduled. Storing one whose parent trigger the store does not hold throws ObjectDoesNotExistException instead of waiting for ever. A scheduling file may still name a parent declared later in the same file — triggers are stored parent-first — but a parent in another file, or scheduled by a later call, has to come first.
  • A released continuation is an ordinary trigger. It forgets its parent (its ContinuesAfter reads null), waits behind its job when that job disallows concurrent execution and is running, honours its calendar and end time — one released past its end time is discarded — and a continuation that is discarded takes everything waiting on it with it.
  • A store-attached window cannot be started. Start() on one — from code or over the HTTP API, which also refuses standby and shutdown for it — throws before anything runs, where it used to run the cluster's start-up recovery against a live database. During a mixed 4.1/4.2 window, do not pause, resume or reschedule a continuation from a 4.1 node.
    ... (truncated)

Commits viewable in compare view.

Updated Quartz.AspNetCore from 4.1.1 to 4.2.0.

Release notes

Sourced from Quartz.AspNetCore's releases.

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 the HTTP API

Nothing was removed or reshaped. Baseline diff v4.1.1..v4.2.0: Quartz 111 added member lines, 0 removed, twelve of them default interface members; Quartz.Dashboard 12 added, 0 removed (24 lines re-ordered by the generator); Quartz.AspNetCore and Quartz.HttpClient unchanged. The Quartz package now depends on nothing new and carries analyzers/dotnet/cs/Quartz.Analyzers.dll and buildTransitive/net10.0/Quartz.targets, which reads DisableQuartzAnalyzers.

Schema

database/migrations/4.2/add_continuations_<dialect>.sql adds CONTINUES_TRIGGER_NAME, CONTINUES_TRIGGER_GROUP and CONTINUATION_CONDITION to QRTZ_TRIGGERS, nullable. Required from 4.2.0: a 4.2 node refuses to start against a database without them, naming the script. Safe to apply while 4.0 and 4.1 nodes run — they never read the columns — but a 4.1 node cannot settle a continuation, so migrate, roll every node, then start scheduling them. 4.2/add_execution_history_<dialect>.sql adds QRTZ_EXECUTION_HISTORY and QRTZ_MISFIRE_HISTORY, optional: needed only with UseExecutionHistory(); a fresh install and ProvisionSchema() create them regardless.

Behaviour changes worth noting

  • TriggerState.Awaiting is a new value on the wire; a 4.1 Quartz.HttpClient reading a 4.2 host that has continuations sees a state it does not know — upgrade the client. A store outside this repository that overrides TriggeredJobComplete keeps working (FiringComplete forwards to it) and settles no continuations until it implements the new member.
  • Quartz.nupkg carries an analyzer. A project whose cron or timeout literals were wrong builds no longer — that is the point — and a build with TreatWarningsAsErrors sees QZ0003 as an error; <DisableQuartzAnalyzers>true</DisableQuartzAnalyzers> opts out, .editorconfig re-tunes a severity.
  • A continuation needs its parent to exist when it is scheduled. Storing one whose parent trigger the store does not hold throws ObjectDoesNotExistException instead of waiting for ever. A scheduling file may still name a parent declared later in the same file — triggers are stored parent-first — but a parent in another file, or scheduled by a later call, has to come first.
  • A released continuation is an ordinary trigger. It forgets its parent (its ContinuesAfter reads null), waits behind its job when that job disallows concurrent execution and is running, honours its calendar and end time — one released past its end time is discarded — and a continuation that is discarded takes everything waiting on it with it.
  • A store-attached window cannot be started. Start() on one — from code or over the HTTP API, which also refuses standby and shutdown for it — throws before anything runs, where it used to run the cluster's start-up recovery against a live database. During a mixed 4.1/4.2 window, do not pause, resume or reschedule a continuation from a 4.1 node.
    ... (truncated)

Commits viewable in compare view.

Updated TinyBDD from 0.19.40 to 0.19.42.

Release notes

Sourced from TinyBDD's releases.

0.19.42

What's Changed

Full Changelog: JerrettDavis/TinyBDD@v0.19.41...v0.19.42

0.19.41

What's Changed

Full Changelog: JerrettDavis/TinyBDD@v0.19.40...v0.19.41

Commits viewable in compare view.

Updated TinyBDD.Xunit from 0.19.40 to 0.19.42.

Release notes

Sourced from TinyBDD.Xunit's releases.

0.19.42

What's Changed

Full Changelog: JerrettDavis/TinyBDD@v0.19.41...v0.19.42

0.19.41

What's Changed

Full Changelog: JerrettDavis/TinyBDD@v0.19.40...v0.19.41

Commits viewable in compare view.

Updated WireMock.Net from 2.16.0 to 2.18.0.

Release notes

Sourced from WireMock.Net's releases.

2.18.0

What's Changed

Full Changelog: wiremock/WireMock.Net@2.17.0...2.18.0

2.17.0

What's Changed

Full Changelog: wiremock/WireMock.Net@2.16.0...2.17.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 update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
  • @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
  • @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
  • @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
  • @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

@dependabot
chore(deps): Bump the nuget-dependencies group with 11 updates
3019b6a 
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 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.2.0
Bumps Quartz.AspNetCore from 4.1.1 to 4.2.0
Bumps TinyBDD from 0.19.40 to 0.19.42
Bumps TinyBDD.Xunit from 0.19.40 to 0.19.42
Bumps WireMock.Net from 2.16.0 to 2.18.0

---
updated-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: 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.2.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: Quartz.AspNetCore
  dependency-version: 4.2.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-dependencies
- dependency-name: TinyBDD
  dependency-version: 0.19.42
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-dependencies
- dependency-name: TinyBDD.Xunit
  dependency-version: 0.19.42
  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>
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.

0 participants