Skip to content

Bump Microsoft.Identity.Client and 10 others - #96

Open
dependabot[bot] wants to merge 1 commit into
developfrom
dependabot/nuget/develop/nuget-remaining-29b587fcb0
Open

Bump Microsoft.Identity.Client and 10 others#96
dependabot[bot] wants to merge 1 commit into
developfrom
dependabot/nuget/develop/nuget-remaining-29b587fcb0

Conversation

@dependabot

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

Copy link
Copy Markdown
Contributor

Updated Microsoft.Identity.Client from 4.90.1 to 4.91.0.

Release notes

Sourced from Microsoft.Identity.Client's releases.

4.91.0

New Features

  • Made the dynamic certificate provider and confidential-client callbacks (OnMsalServiceFailure, OnCompletion, and OnBackgroundTokenRefreshCompleted) generally available, removing the experimental feature opt-in requirement. #​6216

Bug Fixes

  • Fixed built-in mTLS HttpClient caching to use certificate object identity, ensuring a new certificate instance with a reacquired private-key handle receives a new handler even when its thumbprint is unchanged. #​6217
  • Fixed managed identity WithForceRefresh(true) to re-mint the MSI v2 binding certificate before acquiring a new token, while reusing a valid cached attestation token for the current key. #​6215
  • Fixed system-browser authentication callbacks in Linux containers by adding opt-in IPv4 port-forwarding support through MSAL_ALLOW_SYSTEM_BROWSER_PORT_FORWARDING, disabled by default. #​6186

Commits viewable in compare view.

Updated Microsoft.Identity.Client.Extensions.Msal from 4.90.1 to 4.91.0.

Release notes

Sourced from Microsoft.Identity.Client.Extensions.Msal's releases.

4.91.0

New Features

  • Made the dynamic certificate provider and confidential-client callbacks (OnMsalServiceFailure, OnCompletion, and OnBackgroundTokenRefreshCompleted) generally available, removing the experimental feature opt-in requirement. #​6216

Bug Fixes

  • Fixed built-in mTLS HttpClient caching to use certificate object identity, ensuring a new certificate instance with a reacquired private-key handle receives a new handler even when its thumbprint is unchanged. #​6217
  • Fixed managed identity WithForceRefresh(true) to re-mint the MSI v2 binding certificate before acquiring a new token, while reusing a valid cached attestation token for the current key. #​6215
  • Fixed system-browser authentication callbacks in Linux containers by adding opt-in IPv4 port-forwarding support through MSAL_ALLOW_SYSTEM_BROWSER_PORT_FORWARDING, disabled by default. #​6186

Commits viewable in compare view.

Updated Microsoft.Playwright from 1.62.0 to 1.63.0.

Release notes

Sourced from Microsoft.Playwright'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 Quartz from 3.22.0 to 3.22.4.

Release notes

Sourced from Quartz's releases.

3.22.4

Fixes for the 3.x line. The public API gains one property, and there is no schema change. These are ports of fixes found while building Quartz.NET 4.4.

Fixed

  • A trigger whose fire fails every time is stored ERROR instead of being acquired again forever. A trigger whose fire failed on each attempt was released and acquired again in a tight loop, and starved its [DisallowConcurrentExecution] job's other triggers. Five consecutive failed fires of the same occurrence now store it ERROR; ResetTriggerFromErrorState brings it back. (#​3963)

  • A calendar that throws fails only its own trigger. An ICalendar that threw used to strand everything around it:

    • in the in-memory store, the whole fire batch (#​3974);
    • in the in-memory store, the acquisition pass and a completion that unblocks a serial job's triggers (#​3985);
    • in the database stores, a completion: it was retried until shutdown, the job stayed BLOCKED and the worker thread never returned (#​4006). The misfire handler also logged the same trigger on every scan.

    Now the trigger whose calendar threw is left as it was and counted as a failure. The rest of the batch, pass or completion carries on, and a database error is still retried as before.

New

  • JobStoreSupport.MaxConsecutiveFireFailures and RAMJobStore.MaxConsecutiveFireFailures (flat key quartz.jobStore.maxConsecutiveFireFailures), default 5; 0 turns parking off.

Behaviour changes

  • A trigger is parked ERROR after 5 consecutive failed fires. A calendar that keeps throwing while a misfire is handled parks its trigger after 5 failures that are at least a misfire threshold apart, not after 5 quick passes. Set MaxConsecutiveFireFailures = 0 to keep the old behaviour.
  • ResumeTrigger, ResumeTriggers, ResumeJob, ResumeJobs and ResumeAll no longer throw a calendar's exception. They log it and resume the trigger, and its misfire is handled again later.
  • The protected JobStoreSupport.UpdateMisfiredTrigger returns false instead of throwing when a misfire policy throws. It returns true when that failure stored the trigger ERROR.

The same fixes ship in Quartz.NET 4.4.

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

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

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

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

Commits viewable in compare view.

Updated Quartz.Extensions.Hosting from 3.22.0 to 3.22.4.

Release notes

Sourced from Quartz.Extensions.Hosting's releases.

3.22.4

Fixes for the 3.x line. The public API gains one property, and there is no schema change. These are ports of fixes found while building Quartz.NET 4.4.

Fixed

  • A trigger whose fire fails every time is stored ERROR instead of being acquired again forever. A trigger whose fire failed on each attempt was released and acquired again in a tight loop, and starved its [DisallowConcurrentExecution] job's other triggers. Five consecutive failed fires of the same occurrence now store it ERROR; ResetTriggerFromErrorState brings it back. (#​3963)

  • A calendar that throws fails only its own trigger. An ICalendar that threw used to strand everything around it:

    • in the in-memory store, the whole fire batch (#​3974);
    • in the in-memory store, the acquisition pass and a completion that unblocks a serial job's triggers (#​3985);
    • in the database stores, a completion: it was retried until shutdown, the job stayed BLOCKED and the worker thread never returned (#​4006). The misfire handler also logged the same trigger on every scan.

    Now the trigger whose calendar threw is left as it was and counted as a failure. The rest of the batch, pass or completion carries on, and a database error is still retried as before.

New

  • JobStoreSupport.MaxConsecutiveFireFailures and RAMJobStore.MaxConsecutiveFireFailures (flat key quartz.jobStore.maxConsecutiveFireFailures), default 5; 0 turns parking off.

Behaviour changes

  • A trigger is parked ERROR after 5 consecutive failed fires. A calendar that keeps throwing while a misfire is handled parks its trigger after 5 failures that are at least a misfire threshold apart, not after 5 quick passes. Set MaxConsecutiveFireFailures = 0 to keep the old behaviour.
  • ResumeTrigger, ResumeTriggers, ResumeJob, ResumeJobs and ResumeAll no longer throw a calendar's exception. They log it and resume the trigger, and its misfire is handled again later.
  • The protected JobStoreSupport.UpdateMisfiredTrigger returns false instead of throwing when a misfire policy throws. It returns true when that failure stored the trigger ERROR.

The same fixes ship in Quartz.NET 4.4.

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

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

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

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

Commits viewable in compare view.

Updated Quartz.Plugins from 3.22.0 to 3.22.4.

Release notes

Sourced from Quartz.Plugins's releases.

3.22.4

Fixes for the 3.x line. The public API gains one property, and there is no schema change. These are ports of fixes found while building Quartz.NET 4.4.

Fixed

  • A trigger whose fire fails every time is stored ERROR instead of being acquired again forever. A trigger whose fire failed on each attempt was released and acquired again in a tight loop, and starved its [DisallowConcurrentExecution] job's other triggers. Five consecutive failed fires of the same occurrence now store it ERROR; ResetTriggerFromErrorState brings it back. (#​3963)

  • A calendar that throws fails only its own trigger. An ICalendar that threw used to strand everything around it:

    • in the in-memory store, the whole fire batch (#​3974);
    • in the in-memory store, the acquisition pass and a completion that unblocks a serial job's triggers (#​3985);
    • in the database stores, a completion: it was retried until shutdown, the job stayed BLOCKED and the worker thread never returned (#​4006). The misfire handler also logged the same trigger on every scan.

    Now the trigger whose calendar threw is left as it was and counted as a failure. The rest of the batch, pass or completion carries on, and a database error is still retried as before.

New

  • JobStoreSupport.MaxConsecutiveFireFailures and RAMJobStore.MaxConsecutiveFireFailures (flat key quartz.jobStore.maxConsecutiveFireFailures), default 5; 0 turns parking off.

Behaviour changes

  • A trigger is parked ERROR after 5 consecutive failed fires. A calendar that keeps throwing while a misfire is handled parks its trigger after 5 failures that are at least a misfire threshold apart, not after 5 quick passes. Set MaxConsecutiveFireFailures = 0 to keep the old behaviour.
  • ResumeTrigger, ResumeTriggers, ResumeJob, ResumeJobs and ResumeAll no longer throw a calendar's exception. They log it and resume the trigger, and its misfire is handled again later.
  • The protected JobStoreSupport.UpdateMisfiredTrigger returns false instead of throwing when a misfire policy throws. It returns true when that failure stored the trigger ERROR.

The same fixes ship in Quartz.NET 4.4.

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

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

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

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

Commits viewable in compare view.

Updated Quartz.Plugins.TimeZoneConverter from 3.22.0 to 3.22.4.

Release notes

Sourced from Quartz.Plugins.TimeZoneConverter's releases.

3.22.4

Fixes for the 3.x line. The public API gains one property, and there is no schema change. These are ports of fixes found while building Quartz.NET 4.4.

Fixed

  • A trigger whose fire fails every time is stored ERROR instead of being acquired again forever. A trigger whose fire failed on each attempt was released and acquired again in a tight loop, and starved its [DisallowConcurrentExecution] job's other triggers. Five consecutive failed fires of the same occurrence now store it ERROR; ResetTriggerFromErrorState brings it back. (#​3963)

  • A calendar that throws fails only its own trigger. An ICalendar that threw used to strand everything around it:

    • in the in-memory store, the whole fire batch (#​3974);
    • in the in-memory store, the acquisition pass and a completion that unblocks a serial job's triggers (#​3985);
    • in the database stores, a completion: it was retried until shutdown, the job stayed BLOCKED and the worker thread never returned (#​4006). The misfire handler also logged the same trigger on every scan.

    Now the trigger whose calendar threw is left as it was and counted as a failure. The rest of the batch, pass or completion carries on, and a database error is still retried as before.

New

  • JobStoreSupport.MaxConsecutiveFireFailures and RAMJobStore.MaxConsecutiveFireFailures (flat key quartz.jobStore.maxConsecutiveFireFailures), default 5; 0 turns parking off.

Behaviour changes

  • A trigger is parked ERROR after 5 consecutive failed fires. A calendar that keeps throwing while a misfire is handled parks its trigger after 5 failures that are at least a misfire threshold apart, not after 5 quick passes. Set MaxConsecutiveFireFailures = 0 to keep the old behaviour.
  • ResumeTrigger, ResumeTriggers, ResumeJob, ResumeJobs and ResumeAll no longer throw a calendar's exception. They log it and resume the trigger, and its misfire is handled again later.
  • The protected JobStoreSupport.UpdateMisfiredTrigger returns false instead of throwing when a misfire policy throws. It returns true when that failure stored the trigger ERROR.

The same fixes ship in Quartz.NET 4.4.

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

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

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

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

Commits viewable in compare view.

Updated Quartz.Serialization.SystemTextJson from 3.22.0 to 3.22.4.

Release notes

Sourced from Quartz.Serialization.SystemTextJson's releases.

3.22.4

Fixes for the 3.x line. The public API gains one property, and there is no schema change. These are ports of fixes found while building Quartz.NET 4.4.

Fixed

  • A trigger whose fire fails every time is stored ERROR instead of being acquired again forever. A trigger whose fire failed on each attempt was released and acquired again in a tight loop, and starved its [DisallowConcurrentExecution] job's other triggers. Five consecutive failed fires of the same occurrence now store it ERROR; ResetTriggerFromErrorState brings it back. (#​3963)

  • A calendar that throws fails only its own trigger. An ICalendar that threw used to strand everything around it:

    • in the in-memory store, the whole fire batch (#​3974);
    • in the in-memory store, the acquisition pass and a completion that unblocks a serial job's triggers (#​3985);
    • in the database stores, a completion: it was retried until shutdown, the job stayed BLOCKED and the worker thread never returned (#​4006). The misfire handler also logged the same trigger on every scan.

    Now the trigger whose calendar threw is left as it was and counted as a failure. The rest of the batch, pass or completion carries on, and a database error is still retried as before.

New

  • JobStoreSupport.MaxConsecutiveFireFailures and RAMJobStore.MaxConsecutiveFireFailures (flat key quartz.jobStore.maxConsecutiveFireFailures), default 5; 0 turns parking off.

Behaviour changes

  • A trigger is parked ERROR after 5 consecutive failed fires. A calendar that keeps throwing while a misfire is handled parks its trigger after 5 failures that are at least a misfire threshold apart, not after 5 quick passes. Set MaxConsecutiveFireFailures = 0 to keep the old behaviour.
  • ResumeTrigger, ResumeTriggers, ResumeJob, ResumeJobs and ResumeAll no longer throw a calendar's exception. They log it and resume the trigger, and its misfire is handled again later.
  • The protected JobStoreSupport.UpdateMisfiredTrigger returns false instead of throwing when a misfire policy throws. It returns true when that failure stored the trigger ERROR.

The same fixes ship in Quartz.NET 4.4.

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

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

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

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

Commits viewable in compare view.

Pinned Scalar.AspNetCore at 2.18.0.

Release notes

Sourced from Scalar.AspNetCore's releases.

No release notes found for this version range.

Commits viewable in compare view.

Updated TUnit.Playwright from 1.68.4 to 1.74.0.

Release notes

Sourced from TUnit.Playwright's releases.

1.74.0

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.73.19...v1.74.0

1.73.19

What's Changed

Other Changes

Dependencies

New Contributors

Full Changelog: thomhurst/TUnit@v1.73.5...v1.73.19

1.73.5

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.73.0...v1.73.5

1.73.0

What's Changed

Other Changes

Dependencies

New Contributors

Full Changelog: thomhurst/TUnit@v1.72.16...v1.73.0

1.72.16

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.72.10...v1.72.16

1.72.10

What's Changed

Other Changes

Dependencies

New Contributors

Full Changelog: thomhurst/TUnit@v1.72.4...v1.72.10

1.72.4

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.72.0...v1.72.4

1.72.0

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.71.0...v1.72.0

1.71.0

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.70.1...v1.71.0

1.70.1

What's Changed

Other Changes

Full Changelog: thomhurst/TUnit@v1.70.0...v1.70.1

1.70.0

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.69.24...v1.70.0

1.69.24

What's Changed

Other Changes

Dependencies

Full Changelog: thomhurst/TUnit@v1.69.21...v1.69.24

1.69.21

What's Changed

Other Changes

Dependencies

New Contributors

Full Changelog: thomhurst/TUnit@v1.69.16...v1.69.21

1.69.16

What's Changed

Other Changes

Dependencies

New Contributors

Full Changelog: thomhurst/TUnit@v1.69.0...v1.69.16

1.69.0

What's Changed

Other Changes

Dependencies

New Contributors

Full Changelog: thomhurst/TUnit@v1.68.17...v1.69.0

1.68.17

What's Changed

Other Changes

Dependencies

Description has been truncated

@dependabot
dependabot Bot requested a review from w0rldx as a code owner October 12, 2026 19:57
@dependabot dependabot Bot added .NET Pull requests that update .NET code dependencies Pull requests that update a dependency file labels Oct 12, 2026
@dependabot
Bump Microsoft.Identity.Client and 10 others
5e6251c 
Bumps Microsoft.Identity.Client from 4.90.1 to 4.91.0
Bumps Microsoft.Identity.Client.Extensions.Msal from 4.90.1 to 4.91.0
Bumps Microsoft.Playwright from 1.62.0 to 1.63.0
Bumps Quartz from 3.22.0 to 3.22.4
Bumps Quartz.Extensions.Hosting from 3.22.0 to 3.22.4
Bumps Quartz.Plugins from 3.22.0 to 3.22.4
Bumps Quartz.Plugins.TimeZoneConverter from 3.22.0 to 3.22.4
Bumps Quartz.Serialization.SystemTextJson from 3.22.0 to 3.22.4
Bumps Scalar.AspNetCore from 2.17.14 to 2.18.0
Bumps TUnit.Playwright from 1.68.4 to 1.74.0
Bumps Velopack from 1.2.0 to 1.2.161

---
updated-dependencies:
- dependency-name: Microsoft.Identity.Client
  dependency-version: 4.91.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-remaining
- dependency-name: Microsoft.Identity.Client.Extensions.Msal
  dependency-version: 4.91.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-remaining
- dependency-name: Microsoft.Playwright
  dependency-version: 1.63.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-remaining
- dependency-name: Quartz
  dependency-version: 3.22.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-remaining
- dependency-name: Quartz.Extensions.Hosting
  dependency-version: 3.22.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-remaining
- dependency-name: Quartz.Plugins
  dependency-version: 3.22.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-remaining
- dependency-name: Quartz.Plugins.TimeZoneConverter
  dependency-version: 3.22.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-remaining
- dependency-name: Quartz.Serialization.SystemTextJson
  dependency-version: 3.22.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-remaining
- dependency-name: Scalar.AspNetCore
  dependency-version: 2.18.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-remaining
- dependency-name: TUnit.Playwright
  dependency-version: 1.74.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: nuget-remaining
- dependency-name: Velopack
  dependency-version: 1.2.161
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: nuget-remaining
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot changed the title Bump the nuget-remaining group with 11 updates Bump Microsoft.Identity.Client and 10 others Oct 13, 2026
@dependabot
dependabot Bot force-pushed the dependabot/nuget/develop/nuget-remaining-29b587fcb0 branch from d0e0a2b to 5e6251c Compare October 13, 2026 12:31

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

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

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

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

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants