| Name | Modified | Size | Downloads / Week |
|---|---|---|---|
| Parent folder | |||
| Quartz.NET-3.22.5.zip | 2026-10-13 | 52.5 MB | |
| README.md | 2026-10-08 | 1.1 kB | |
| v3.22.5 source code.tar.gz | 2026-10-08 | 5.6 MB | |
| v3.22.5 source code.zip | 2026-10-08 | 6.3 MB | |
| Totals: 4 Items | 64.5 MB | 0 | |
One fix for the 3.x line, ported from Quartz.NET 4.5. There is no public API change and no schema change.
Fixed
- A calendar replacement that throws leaves the in-memory store as it was.
RAMJobStore.StoreCalendar(name, calendar, replaceExisting: true, updateTriggers: true)moved each trigger on the calendar to the replacement one at a time. If the replacement threw for a trigger, three things went wrong: - that trigger dropped out of the schedule for good;
- the triggers before it had already moved on;
- the replacement calendar was already stored.
Now every trigger is recomputed on a copy first. If one throws, the call fails with JobPersistenceException("Couldn't store calendar: …"), worded and wrapped as the database stores do, and nothing changes: the old calendar stays, and every trigger keeps its fire time and its place in the schedule. The failure is the caller's, so it does not count toward MaxConsecutiveFireFailures. (#4039, the port of [#4029] that fixed [#4026])
The same fix ships in Quartz.NET 4.5.
Full Changelog: https://github.com/quartznet/quartznet/compare/v3.22.4...v3.22.5