Add a "Stop run" control — ai.cancelLineupRun exists but has no caller

[area51tazz]

There's no way to stop a running AI lineup run from the admin UI — but the backend for it is already written and wired, just never called.

It already exists

• ai.cancelLineupRun — packages/api/src/routers/ai.ts:138-143
• → requireLineupRunner().cancel(runId) → run.cancel() — apps/server/src/workflow-engine.ts:118-121
• The run detail page already knows how to render the result: TERMINAL_RUN_STATUS includes "cancelled" ($runId.tsx:96), with a badge case at :181 and a colour at :194.

A repo-wide search for cancelLineupRun returns exactly one hit — its own definition. Nothing in apps/web, apps/tv-web or apps/desktop calls it. So the UI can display a cancelled run, it just has no way to create one.

Why it's worth a button

A deterministic plan failure still retries to max_attempts = 3, and each attempt is a full planner call. Concrete case here today, self-hosted, qwen3.6-35b on vLLM:

• Plan attempt 1: AI_NoObjectGeneratedError — finishReason=length rawTextChars=22643, i.e. it hit plannerMaxOutputTokens (32000). Reasoning mode was on, and reasoning + answer share that budget; the same library plans in 12,787 output tokens with thinking off, so it overflowed.
• plannerMaxOutputTokens is frozen into the run's args at dispatch, so raising the setting can't rescue the run in flight.
• Attempts 2 and 3 will therefore fail identically — about 10 minutes each on local hardware. ~20 minutes of GPU time to re-derive a conclusion that was known after attempt 1.

Nothing in the admin UI can stop that.

The workarounds don't work

• Restarting the server doesn't stop a run — it resumes it. Observed here: a run created 2026-09-02, whose plan step failed 3× that day, completed on 2026-09-04 after a container recreate. It then ran wipe-and-rebuild using its original frozen args — so it built at the hardcoded concurrency of 6, predating the channelBuildConcurrency is ignored — the ai-lineup-build job never passes it to the workflow #21 fix that was live by then. A restart is the opposite of an escape hatch.
• Deleting the graphile-worker job leaves workflow_runs.status non-terminal, so the run stays eligible to come back the same way.
• That leaves calling the mutation by hand from the browser console, which is what I ended up doing.

Suggested shape

A Stop run button in the run detail header beside the status badge, shown when !TERMINAL_RUN_STATUS.has(status) — and optionally on the runs-list rows. A confirm step seems reasonable, since stopping mid-build leaves a partially-built lineup.

Happy to test whatever you put together.

[area51tazz]

Refining the above after actually exercising ai.cancelLineupRun (called by hand against /trpc/, since there's still no caller).

It returned {"result":{"data":{"cancelled":true}}} and workflow_runs.status went to cancelled — but the in-flight step kept running upstream. Measured immediately after: the local GPU still at 92% utilisation with requests in the vLLM execution batch, and no trace row was ever written for the attempt that was running.

So the semantics appear to be: mark the run terminal and discard the result, not abort the provider call. Which means a Stop button buys you the remaining attempts, not the current one. In my case that was still worth having — a deterministic plan failure was retrying at max_attempts = 3 with each attempt taking 11 minutes on local hardware, so stopping after attempt 2 saved a third 11-minute call.

Two implications for the feature, if useful:

1. The button is worth it on the "no further attempts" value alone — that's most of the waste on a slow local model.
2. If you wanted the stronger version, it'd need an AbortSignal threaded from the run into the step's provider call so cancelling actually tears down the request. That's obviously a bigger change than wiring up a button, and I'd happily take the button first.

Also worth noting for anyone reading this later: those two 11-minute planner steps ran to completion without any timeout, on 0.12.49. Pre-0.12.49 they'd have died at ~300s. The fix in #22 is doing real work here — they failed on token budget, not on time.

[xxtraPickles]

+1 for this

My workaround has been to set all of the job connections to None, then edit a connection to have a bad endpoint (like changing a port), then set the jobs to the connection with that bad one, and then they usually do a quick fail. Like you mentioned, a server restart just has them pick back up where they left off.

Overall though, with the recent updates, I have had a lot of dry test run successes, but still throwing different models across different hardware looking for the sweet spot.