Found by reading the code while rewriting the docs; not each reproduced. Batch path filtering is filed separately.
A batch with no counted runs (all skipped or reused) passes, but nothing rings the door, so it lands only on the next pass, up to --sweep (600 s) later.
A batch running ahead can take pulls queued after one it left out for conflicting, so pulls can land out of queue order.
When a branch is deleted, its queued pulls stay queued forever.
knotless queue slices &b.commit[..12], which panics on a shorter commit. (Fixed: it uses .get(..12) now.)
--batch above 64 writes a check's batch past the lexicon's maxLength of 64. (Fixed: MAX_BATCH refuses it at start.)
--queue without KNOTLESS_APPVIEW is not refused at start, unlike --pulls.
Each pull's merged state's from is the previous pull's commit in the batch, not the branch's old tip. (Not a bug: state.json now defines from..commit as what the pull brought in.)
Squash commits take the current committer date, so a rebuilt batch never has the same tip, and batch runs dropped at a stop are never resumed.
A pull ejected as the lone suspect after halving gets no commit in its ejected record. (Fixed: failed_heads carries its head into the record.)
Stale comments on turns::Class::Later and Class::Main.
chadtmiller.com/knotless
Found by reading the code while rewriting the docs; not each reproduced. Batch path filtering is filed separately.
.get(..12)now.)MAX_BATCHrefuses it at start.)failed_headscarries its head into the record.)