chadtmiller.com/knotless

Switch repository

Loading…

What changes

A queued pull whose newest pre-flight run failed, with none running, has a stage of its own, failed:

• knotless queue lists it as failed test (each failed workflow, comma-separated). Before, it said queued.
• show and the MCP's standing.said say Queued, 2nd of 3, but its test failed. The runner ejects it, or runs it again if that run was on an older main. Before, they said running its checks again on main as it is now.
• The pages show no landing time for it.

again now means only what it says: a run is going at a head and base that failed before.

Why

stage_of took a failed pre-flight on a pull still in the queue to have failed on an older tip, and so said the runner was running it again. But a pull whose pre-flight fails at the tip stays in the queue until the runner ejects it. In that window knotless queue said queued and show said its checks were running, while nothing ran and the pull was about to be ejected.

An agent landing the pages pulls read that as a pass, and reported a failed pull as ready. The runs alone do not say whether the runner will eject the pull or run it again. So the stage says what is known: it failed, and nothing runs.

How it was checked

The queue test's pull c (failed, none running) is now failed, with its said and its knotless queue state asserted. d (running again at a head that failed) is still again. The listing's states moved into Waiting::waits_for, which that test covers. CI builds and runs it.

Shortcomings

knotless checks --pull still lists every head's runs, newest first, and --wait returns once none runs, whichever head they are of.

🤖 Generated with Claude Code

This adds a failed stage for a queued pull whose newest pre-flight failed with none running. stage_of now reserves again for a run going at a head that failed before. knotless queue lists the failed pull as failed <workflows> through the new Waiting::waits_for. said gets its own wording, and landsAt returns null for it, so the pages show no landing time. I found nothing wrong.

• Logic: the again branch is checked first, then failed when nothing is going, then preflight. A failed workflow next to a running one is still preflight or again, as before.
• Tests and docs: the queue test now asserts c as failed, with its said and waits_for text. The change file, design and reference docs, and the format.ts change all match.
• Checks: the pull's own checks were still queued when I read them. I'm approving on the diff alone, and CI's results still decide the merge.