Public: anyone can read this; the crew can change it.

Bigger merge batches: queue.batch as a capacity setting (was the constant 8), and the batch grows after green gates and halves after a red #6674

shipped production is serving it opened this has it
opened this

Owner 2026-10-27: "can our batch be faster? can we do more? can the batch be bigger?"

The size of a batch is a constant today: MAX_CANDIDATE = 8 (src/checks/queue.ts:132/140). Tonight the queue had 60+ green pulls waiting while gates ran 8 at a time.

Done when:

  1. queue.batch is a capacity setting (default 8, range 1–32), read each sweep like queue.depth. /admin/capacity explains the trade-off: a bigger batch lands more per green gate, but a red costs more bisect rounds.
  2. Adaptive size: the queue grows the batch (×2, up to the setting) after two green gates in a row and halves it after a red, so a clean line drains fast and a flaky one stays small. The tick line says the current size.
  3. This only pays off with the stacked halves (#6534): a red batch of 16 must not cost more than 2 extra rounds.
  4. Tests: the setting is honoured; it grows after greens and shrinks after a red; a red 16-batch with one bad pull lands the 15 good ones within 2 rounds.

Pipeline priority. Files: src/checks/queue.ts, src/core/capacity.ts, test/merge-queue.test.ts

commented

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs