Development record
2026-10-17 — Refines dcn-2610161814279204, the two-preflights trial (iss-2610161639025702), on how the two gates share the hold. Each gate now keeps its own hold record, the first gate's in load-wait.json, the name it had before the race gate existed, and the race gate's in load-wait-race.json, and a wait judges and takes only its own gate's record. A first gate's command hold, taken by --wait -- make preflight, lasts until its preflight starts its race run, up to sixty minutes. While it also shut the race gate, an earlier preflight's race waiter on the same account waited on it, and the holder's own race waiter, which the hold does not shut because the holder is its ancestor, queued behind that earlier race waiter, which started earlier and has the lower pid; neither moved until its timeout. Even without the cycle, the earlier preflight's race stage waited out the holder's whole test stages. Rejected: letting a race waiter beneath a holder jump the race queue, as the first gate's waiter beneath one does. It breaks the cycle but keeps the stall, and since the queue is read across accounts, it would let that race waiter open beside another account's race waiter queued ahead of it, two race stages at once. Cost of the chosen fix: the first gate is no longer shut for two minutes after a race gate opens, nor the race gate after a first gate opens; with two slots each running preflight still takes a slot, and the load limit still applies, so nothing the trial relies on is lost. An abcd released before the race gate reads only load-wait.json, as before.
2026-10-17 — Refines dcn-2610161814279204, the two-preflights trial (iss-2610161639025702), on how the two gates share the hold. Each gate now keeps its own hold record, the first gate's in load-wait.json, the name it had before the race gate existed, and the race gate's in load-wait-race.json, and a wait judges and takes only its own gate's record. A first gate's command hold, taken by --wait -- make preflight, lasts until its preflight starts its race run, up to sixty minutes. While it also shut the race gate, an earlier preflight's race waiter on the same account waited on it, and the holder's own race waiter, which the hold does not shut because the holder is its ancestor, queued behind that earlier race waiter, which started earlier and has the lower pid; neither moved until its timeout. Even without the cycle, the earlier preflight's race stage waited out the holder's whole test stages. Rejected: letting a race waiter beneath a holder jump the race queue, as the first gate's waiter beneath one does. It breaks the cycle but keeps the stall, and since the queue is read across accounts, it would let that race waiter open beside another account's race waiter queued ahead of it, two race stages at once. Cost of the chosen fix: the first gate is no longer shut for two minutes after a race gate opens, nor the race gate after a first gate opens; with two slots each running preflight still takes a slot, and the load limit still applies, so nothing the trial relies on is lost. An abcd released before the race gate reads only load-wait.json, as before.
Frontmatter
| id | dcn-2610170141139286 |
|---|---|
| type | decision |
| date | 2026-10-17 |
.abcd/work/decisions/dcn-2610170141139286-refines-dcn-2610161814279204-the.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26101618142792042026-10-16 — The product thinker approved a measured trial of two preflights in their test stages at once, with the race stage kept to one at a time; the default stays one, and a person may raise it only for their own machine (load.preflights in ~/.abcd.noindex/config.json, or ABCD_LOAD_PREFLIGHTS), never from a repository file. So the setting takes 1 or 2 and nothing more: 3 and 4 are refused, saying the limit rises once a measured trial supports it. At the default of one the preflight runs exactly as before, its race gate opening at once.
- iss-2610161639025702Preflight throughput sets the pace of all work on this machine, and nothing keeps it in bounds. On 2026-10-16 the load gate admitted one make preflight at a time, each took about 40 minutes, and about 20 waiters were queued across seven sessions. Every reviewed branch had its own preflight, so a seven-step feature needed seven full runs, and records-only branches paid the same full cost as code. Sessions waited hours, and the queue's ordering after the reboot starved late waiters (fixed separately on fix/load-queue-start-order). No rule tells sessions to batch work, and no part of preflight scales its cost to what a change touches.