chadtmiller.com/knotless

Switch repository

Loading…

What changes

A merge queue's batch built ahead goes first once the batch under it lands. It waits for a job as a pull's run does while the batch under it is still being checked, as before. Once that one lands, its runs still waiting leave their place and wait again with pushes to the default branch, in the order they were started in, and those that start from then on take main's CPU share.

Why

The batch's class was fixed when its runs were filed, so a batch built ahead stayed in Later after it became the batch that lands next, behind every pre-flight and pull run. On runner.knotless.dev on 2026-11-07, from its journal between 17:17 and 21:20 UTC:

• batches built ahead waited 225 of the 271 minutes main's runs spent waiting for a job;
• batches not built ahead waited a median of 0.5 minutes, 2.4 at the 90th percentile;
• batch 9046f670 waited 34 to 42 minutes after b54305a5 landed under it, while about 20 pull runs started first, some filed after it.

The same data argues against changing the host's settings: holding jobs back for main with a lower --pull-jobs would save little once this lands, and main has no run going or waiting for 26% of the time, when a held job would sit idle.

How it was checked

turns::tests::promoted_goes_as_main checks that a run promoted while it waits takes main's job at once, past a pull's run. a_batch_ahead_goes_first_once_the_one_it_is_on_lands has a pre-flight hold the pulls' share while two batches go: the batch built ahead lands once the one under it does. Without the promotion it never lands, and the test times out. Both pass here, as do a_merge_queue_runs_ahead and a_merge_queue_runs_ahead_with_a_job_to_spare. The rest is left to CI.

Shortcomings

A run of the batch ahead already going when it is promoted keeps a pull's CPU share until it ends. The job the batch under it frees as it ends can still go to a pull's run before the landing promotes the batch ahead, so that batch may wait for the next job to come free.

🤖 Generated with Claude Code

This makes a batch built ahead go as main's once the batch under it lands. Batch.ahead becomes a watch channel, and the landing loop in queue.rs calls promote() on the next flight right after it removes the landed one. A run of that batch that still waits for a job as a Later run drops its place and waits again as Main, keeping its start order. Runs filed after the promotion read first() and are ranked Main from the start.

I found no bugs. I did not run the tests or read the CI checks, and I took the test results from the pull body. What I checked by reading:

• promoted() subscribes before it checks the current value, so a promotion between ranking and waiting is not missed.
• The biased select drops the first take before the second starts, so the run never holds two places.
• The Class::Later filter keeps the Asked and Other classes out of the promotion.
• The docs, the module comment and the changeset are updated with the change.