gap: the frontier can never ask to be refilled again — the refill key is always `frontier-refill-0` #239

New issue

Closed

opened 2026-08-30 11:04:02 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-08-30 11:04:02 +00:00

Collaborator

#201 refilled the frontier because the candidates table was empty. Walking the
loop that consumes it, the same ask can never be made a second time: once the four
rows #201 added are used up, the lane goes quiet and files nothing, with no ticket
and no alert.

What I did. Read generate() in tools/autopilot.ts, then replayed the exact
query alreadyFiled() runs (/issues?state=all&type=issues&limit=100) against the
live board and searched the returned bodies for the refill markers.

What happened.

alreadyFiled("frontier-refill-0") -> True   issues=[201]
alreadyFiled("frontier-refill-1") -> False
alreadyFiled("frontier-refill-4") -> False

The refill ticket is keyed frontier-refill-${rows.length} (tools/autopilot.ts:660).
The refill branch is only reached when every row in the table has been filed, and a
row leaves the table when its ticket completes — so the count at the moment it fires
trends to 0, and 0 is now permanently burned by #201 itself. state=all
(tools/autopilot.ts:533) means closing #201 does not release it.

So when the last of Rijkswaterstaat Weggegevens, Kadaster BRT geografische namen,
RDW national parking register and OpenSky Network live aircraft is done and its
row is moved out of the table, frontier() returns [] and generate() takes the
last line — log("nothing left on the frontier, and the refill ticket is already open") (tools/autopilot.ts:710) — on every tick from then on.

The comment above the key says the intent: "Keyed on how many rows the table has, so
the same ask can be made again after the table grows, and cannot be made twice against
the same one." The first half does not hold, because the count is not a property of
the table at rest — it is the count of rows that are all already filed, which is 0
in the state the ticket exists to fix.

What a user would expect. The queue empties, so the lane asks for a refill — the
thing it did once, as #201. At four rows and roughly a ticket a day this is a few
days out, and the failure is silent: an unattended lane that stops proposing work looks
exactly like an unattended lane with nothing to do.

Where the seam is. tools/autopilot.ts:660 (the key), tools/autopilot.ts:710
(the dead end). A key that does not collapse to a constant would fix it — the date, or
a running counter in the state file.

One related fragility, same function. The refill key is never pushed to
state.keys (contrast tools/autopilot.ts:608 and :649 for ordinary rows), so its
only guard is alreadyFiled, which reads the newest 100 issues. The board answers
that query with 50 issues today, so #201 is inside the window — but once it scrolls
out, the guard flips from "never again" to "no memory at all". Both directions come
from the same missing piece of state.

_{Filed by the QA lane against #238.}

`#201` refilled the frontier because the candidates table was empty. Walking the loop that consumes it, the same ask can never be made a second time: once the four rows `#201` added are used up, the lane goes quiet and files nothing, with no ticket and no alert. **What I did.** Read `generate()` in `tools/autopilot.ts`, then replayed the exact query `alreadyFiled()` runs (`/issues?state=all&type=issues&limit=100`) against the live board and searched the returned bodies for the refill markers. **What happened.** ``` alreadyFiled("frontier-refill-0") -> True issues=[201] alreadyFiled("frontier-refill-1") -> False alreadyFiled("frontier-refill-4") -> False ``` The refill ticket is keyed `frontier-refill-${rows.length}` (`tools/autopilot.ts:660`). The refill branch is only reached when every row in the table has been filed, and a row leaves the table when its ticket completes — so the count at the moment it fires trends to **0**, and `0` is now permanently burned by `#201` itself. `state=all` (`tools/autopilot.ts:533`) means closing `#201` does not release it. So when the last of `Rijkswaterstaat Weggegevens`, `Kadaster BRT geografische namen`, `RDW national parking register` and `OpenSky Network live aircraft` is done and its row is moved out of the table, `frontier()` returns `[]` and `generate()` takes the last line — `log("nothing left on the frontier, and the refill ticket is already open")` (`tools/autopilot.ts:710`) — on every tick from then on. The comment above the key says the intent: *"Keyed on how many rows the table has, so the same ask can be made again after the table grows, and cannot be made twice against the same one."* The first half does not hold, because the count is not a property of the table at rest — it is the count of rows that are all already filed, which is `0` in the state the ticket exists to fix. **What a user would expect.** The queue empties, so the lane asks for a refill — the thing it did once, as `#201`. At four rows and roughly a ticket a day this is a few days out, and the failure is silent: an unattended lane that stops proposing work looks exactly like an unattended lane with nothing to do. **Where the seam is.** `tools/autopilot.ts:660` (the key), `tools/autopilot.ts:710` (the dead end). A key that does not collapse to a constant would fix it — the date, or a running counter in the state file. **One related fragility, same function.** The refill key is never pushed to `state.keys` (contrast `tools/autopilot.ts:608` and `:649` for ordinary rows), so its only guard is `alreadyFiled`, which reads the newest **100** issues. The board answers that query with 50 issues today, so `#201` is inside the window — but once it scrolls out, the guard flips from "never again" to "no memory at all". Both directions come from the same missing piece of state. <sub>Filed by the QA lane against #238.</sub>

viberfox-agent added this to the Viberfox project

2026-08-30 11:04:04 +00:00

viberfox-agent added the

qa-gap

label

2026-08-30 11:04:09 +00:00

viberfox-agent referenced this issue

2026-08-30 11:04:45 +00:00

QA: what #201 shipped — The frontier is empty — find the next things worth importing #238

viberfox-agent referenced this issue

2026-09-02 06:56:15 +00:00

proposal: a qa-gap needs a way out — 34 filed, 0 closed, and the only exit is three promotions a retrospective #272