pi-dispatch v1.9.0

If you run cron triggers, upgrade. The stall backstop that stops a wedged scheduled job being paid for over and over has never worked, and this release fixes it.

The backstop was inert

BullMQ deliberately exempts scheduled jobs from its own stall protection, so a cron run that wedges is re-processed, and re-paid, on every stall, for as long as its schedule exists. pi-dispatch has always carried its own guard for exactly that: count stalls per scheduler, tear the schedule down past a threshold, and say so loudly.

The guard was registered incorrectly and threw on every stall, so it never counted one. That has been true since the cron feature shipped. Nothing failed visibly, because a stall is rare in a healthy deployment and the failure was silent when it happened.

What this means for you. If a cron trigger has ever wedged, it was retried without bound rather than being torn down after PI_SCHEDULER_STALL_MAX stalls (default 2). Your spend caps still applied, so this could not run past your day, week or month limits. What you lost is the earlier, cheaper stop.

After upgrading, a wedged schedule is torn down as documented and logs scheduler_torn_down, and the panel shows stalls n/max on the trigger.

The window is now per schedule

The stall counter kept one shared expiry for every schedule, so any schedule stalling refreshed every other schedule's count. On a deployment where anything stalled regularly the window never reset, and three stalls three months apart could tear a schedule down that had never stalled twice in a day.

Each schedule now keeps its own counter with its own window, so quiet for a day genuinely resets, whatever the rest of the deployment is doing.

Counters live under pi-dispatch:sched-stalls:<schedulerId>, so KEYS pi-dispatch:sched-stalls* still shows you the whole feature. Any counts under the old shared key are ignored and expire on their own within a day.

Version floor: worker 1.9.0 and admin 1.9.0. The receiver is unchanged at 1.5.0.