Rerun terminally-failed scheduled jobs in place, with failure backoff

[dereuromark]

Pairs with dereuromark/cakephp-queue#504 (which persists terminal aborted state). Dormant and behaviour-preserving on older queue releases.

Problem

A non-concurrent row gates its next dispatch on QueuedJobsTable::isQueued(). Once the queue records terminal aborted state, a dead job stops counting as queued and the schedule resumes — but it would then queue a brand-new job every tick, leaving one failed row behind per interval (≈1440/day for an every-minute task). That's a different failure mode from the wedge, and it's noisy.

1 — Rerun in place

When the row's previous dispatch terminally failed (queue status = aborted), run() resets that same job (clears attempts + the stale aborted status) instead of creating a new one. One recycled row per logical scheduled job, no pile-up.

• Checked before the in-flight hold-back, so it works whether or not the installed queue release already excludes aborted jobs from isQueued() (#504) — an aborted job is terminal and never blocks.
• Still-retrying jobs are untouched: while attempts remain the job is genuinely in flight and the next tick is held back as before, so there is no early re-dispatch.

2 — Backoff + disable + alert

A new consecutive_failures counter tracks aborts without an intervening success. After QueueScheduler.maxConsecutiveFailures (default 0 = unlimited) the row is disabled and a QueueScheduler.Row.disabled event is dispatched so the host app can alert. A successful / fresh dispatch resets the counter.

$this->getEventManager()->on('QueueScheduler.Row.disabled', function ($event) {
    $row = $event->getData('row');
    $failures = $event->getData('consecutiveFailures');
    // notify ops…
});

Transaction note

The disable write must commit while run() still reports "not dispatched". The transactional() callback returns true (commit) for both a dispatch and a backoff-disable, and only false (rollback) for hold-back / lost compare-and-swap. The actual dispatched result is tracked in an outer flag — returning false from the callback would roll the disable back (that was a real bug caught in testing).

Changes

• consecutive_failures column: migration + fixture + entity property.
• run() rerun/backoff logic + abortedJobId() helper.
• 3 tests (testRunRerunsAbortedJobInsteadOfCreatingNew, testRunDisablesRowAfterMaxConsecutiveFailures, testRunResetsFailureCounterOnFreshDispatch).
• Config documented in docs/README.md + config/app.example.php.

SchedulerRowsTableTest green (28); phpcs clean; phpstan clean on the changed table file. (A pre-existing json_decode flags/depth phpstan note in SchedulerRow::_getJobData() is unrelated and only surfaces under newer phpstan than the pinned CI version.)