Jobs control surface — stretch: pause/resume, edit-trigger, last/next-run, more run-now loops

[coaxk]

Follow-up to #234 (the run-now MVP shipped: jobs.py registry + POST /api/health/tasks/{name}/run + Run-now buttons for update-checker & queue-feeder).

Remaining scope from the original #234:

• last-run / next-run columns on the Health page (compute next-fire from last_success_at + expected_interval_s; scheduler jobs from schedule_store).
• pause / resume per loop, persisted across restarts (enable/disable flag in schedule_store / a job-state table).
• edit-trigger for the scheduler jobs (interval/daily/weekly), reusing schedule_store.
• run-now for more loops — coverage-cache and dashboard-cache refresh() take build args, so they need a no-arg trigger wrapper; completion-watcher could expose a poll-now.

Borrowed-from: sublarr Settings -> System -> Scheduler. Builds on #157 task_health + the #234 MVP.

[coaxk]

Partial: last/next-run shipped (PR #256) — TaskHealth.next_run_at + a next in Xm column on the Health page, on top of the #234 run-now MVP. So the read-only scheduler-admin view (last-run / next-run / run-now) is now complete.

Still open (the heavier half, each needs real plumbing):

• pause/resume — per-loop gating across 7 heterogeneous background loops + a persisted enable/disable flag. The biggest piece; needs a central JobControl + each loop honouring it.
• edit-trigger — interval/daily/weekly editing for the scheduler jobs (reuse schedule_store).
• run-now for more loops — coverage-cache/dashboard-cache refresh() take build args, so they need a no-arg trigger wrapper; completion-watcher could expose poll-now.

[coaxk]

Triage, 2026-08-30. Still valid, and cheaper now than when it was written.

Both foundations are complete: #234 shipped the run-now MVP, and #157 Phase 1 is done (supervision primitive, /api/health/tasks, Health page, header pill, SUBARR_DEBUG).

More usefully, the last-run / next-run columns are now nearly free. #472 registered five tasks that recorded health but were never seeded (telemetry, data-persistence, data-network-fs, db-integrity, single-process), so every reporting task now has a row. Before that those five were absent from the roster until their first success, which would have made a next-run table quietly incomplete rather than obviously wrong. The data this issue wants to render is finally all present.

Remaining scope reads accurately as written. Rough order of value against effort:

1. last-run / next-run columns - mostly a computation over data already on the roster (last_success_at + expected_interval_s), plus schedule_store for scheduler jobs.
2. run-now for more loops - the noted blocker still applies: coverage-cache and dashboard-cache refresh() take build args, so they need a no-arg trigger wrapper.
3. pause / resume - needs persistence, so it is the first piece that adds state rather than reading it.
4. edit-trigger - largest, and the least obviously wanted.

⚠️ One caution for whoever picks it up: expected_interval_s is deliberately None for the event-driven tasks (audio-audit, forced-segment, and the four one-shots added in #472) so the staleness branch never fires for them. A next-run column must render those as "on demand" rather than computing a fictional next fire time, or it will invent a schedule that does not exist.

[coaxk]

Correction to yesterday's triage, then what I am actually shipping.

I was wrong about item 1

I said the last-run / next-run columns were "mostly a computation over data already on the roster" and ranked them first by value against effort. They were already built. Commit 11b824f, "feat(health): last/next-run on the Jobs surface (#252 slice) (#256)", shipped them: TaskHealth.next_run_at computes last_success_at + expected_interval_s, to_dict serialises it, and health.jsx renders ok <ago> and next <until> with the event-driven case correctly left blank.

The caution I attached to it was also already honoured in that commit. So the useful correction is just: item 1 is done, and my ranking was based on not having read the code.

Item 2 is what remains, and it is where the value is

Shipping now:

Four more loops get Run now. coverage-cache, dashboard-cache, subgen-watchdog and completion-watcher, up from the two the #234 MVP covered. subgen-watchdog is the one worth calling out: #479 found that half of genuine installs report their subgen as unreachable, so an on-demand re-probe is the button most of those users actually want rather than waiting out the interval.

The blocker was real and is solved without duplicating wiring. coverage_cache.refresh() takes bundle, probe_store, audio_lang_store, probe_walker and caps_provider, several of them closures. Rebuilding that argument list inside the jobs registry would have been a second copy of the loop's wiring, free to drift, and the drift would be invisible: the button would keep working while quietly running something other than what the schedule runs. Instead there is now one make_refresh_trigger factory; app.py builds the trigger once, registers it, and hands the same object to the loop. A test captures the arguments of the scheduled refresh and of the triggered refresh and requires them to be identical.

Two exclusions, both deliberate. scheduler stays monitor-only because a tick fires due jobs, so it starts real scans rather than refreshing a view, and that needs its own confirmation rather than a button identical to the others. db-integrity already has a dedicated manual endpoint from #291 Slice B, and a second trigger would be a divergent copy of one control. Both are pinned by tests so the reasoning is not lost.

Two bugs found while building it

Run now failed silently. fetch does not reject on an HTTP error status, so the handler's .then(() => load()).catch(() => {}) ran its success path on a 409 and the catch only ever saw network errors. Clicking Run now on a job that could not fire did nothing observable at all. Harmless when the only triggers were an update poll and a feeder kick; not once a coverage refresh reaches out to Bazarr, Sonarr and Plex, where not-firing is routine.

run_job could return a 500. Its docstring has always said "Never raises, a control action must not 500 the page". Nothing caught an exception from the trigger, and the endpoint does not either. It is now caught, and the message is redacted first, because integrations carry their credential in the request URL and subarr serves its own recent log over /api/logs/recent on an install that may have no auth.

And one design flaw of my own, caught by a test that boots the real lifespan: the triggers originally registered inside the loop coroutine, which does not execute until the event loop schedules it, while the button renders from a static registry. Buttons guaranteed to render with nothing behind them. Registration is now eager, before create_task.

Still open under this issue

Items 3 and 4, pause/resume and edit-trigger, both unchanged in scope. Pause/resume is the first piece that adds persisted state rather than reading it.