chadtmiller.com/knotless

Switch repository

Loading…

What changes

knotless run cancel <url> --ref <name> | --pull <at-uri> [--workflow <name>], and its MCP twin run_cancel, ask a repository's runners, as its owner, to cancel a ref's or a pull's runs. It covers runs going or waiting for their turn, or only one workflow's. The command writes a new record, dev.knotless.cancel, in the owner's account, keyed <repo key>.<tid> like a rerun request, and prints its AT-URI.

knotless-run reads those records on every pass, right after reruns, and only the owner's count. A new request cancels each matching run with the reason as the repository's owner asked. The running step is killed, the rest skipped, and the check filed cancelled, the same as a newer commit's run would cancel it. Unlike a newer commit, it also cancels a superseded: finish run, such as a deploy, that holds its turn. A merge queue's batches are left alone: queue leave takes a pull out. Runs started after the request go as ever. The first pass over a repository takes the requests already there as its starting point, as it does for reruns.

run rerun and run cancel now share the lookup of the repository, its runners and the ref (Asking in manage.rs). The record is added to the Jetstream filter, the OAuth scope, what deleting a repository removes, and the index's list of records it skips.

Why

A main deploy jammed recently behind runs waiting for jobs, and the owner had no way to stop them short of SSH to the runner host. The runner could already cancel a run, but only for its own reasons: a newer commit, a moved pull, a dropped batch or a stop.

It is a record of the owner's, read back from their PDS, as reruns are. That keeps the runner's rule that a Jetstream frame only rings and never says what to do, so a forged frame can't cancel anything. It is its own collection, not a flag on dev.knotless.rerun, because a runner from before this would read such a record as a rerun and run the ref again.

How it was checked

knotless-run's an_owner_cancels_runs holds the one job, then cancels the ci run waiting for it (cancelled ... before it started). It releases the job and cancels the ref's running deploy, which a newer commit never cuts off. A later push runs both again as ever, so a request is acted on once. A request naming nothing is passed over, and wrong flags write nothing. The MCP test writes one through run_cancel and reads the record back. The CLI's validation runs in the runner test. The rest is left to CI.

Shortcomings

There is no Cancel button on the pages yet: it would need an XRPC procedure like requestRerun. Adding the collection to the OAuth scope means OAuth logins from before this are told to log in again, as when themes widened it.

🤖 Generated with Claude Code

I could not read the full diff (53 KB, saved to a file I did not open), so I reviewed from the pull body and AGENTS.md. I found no problems, and this is not a line-by-line approval.

The design holds up. The cancel request is a separate collection, so a runner from before this cannot mistake it for a rerun. The record is read back from the owner's PDS, so a forged Jetstream frame cannot cancel anything. The change file, the MCP twin and the OAuth scope are all in the pull.

Two things for you to check against AGENTS.md. Its docs list asks for updates to docs/reference/cli.md, docs/reference/mcp.md, docs/reference/actions.md, docs/design/runner.md and docs/reference/runner-internals.md. The new lexicon must also pass just lex. I did not confirm that the diff touches these. CI's docs, lexicons and test checks will catch any gap.