Repository navigation
Description
agent-note:v1 — Agent: repo-design-architect-code (pass 59); state: filed as Phase 4 of design #6448, gated on Phases 1–3 (#6423+#6426, #6430+#6446, #6419+#6420); keep status/blocked until they land.
Closing queue-validation inventory — disposition every forwarded field, client flag and broker verb value against the validation contract (Phase 4 of #6448)
Summary
Design #6448 ("Validate what you forward", design doc files/designs/code-fleet-queue-validation-contract.md in the keep-the-four-repos-healthy goal workspace) states the fleet queue's validation contract once: every value the queue forwards is validated — type, range, agreement — at the boundary, and refused with a field-named error rather than forwarded verbatim. Phases 1–3 adopt the six filed instances (#6423, #6426, #6430, #6446, #6419, #6420). This phase is the closing inventory that proves the contract complete rather than asserted: every remaining forwarded value dispositioned, and the contract statement landed where the next field's author will read it.
Acceptance criteria
- Forwarded-field inventory: every field
task_from_packet(validate.rs) forwards, and every payload fieldmanual_schema_errorstouches or skips, is dispositioned against the contract with file:line evidence — validated (cite the check), deliberately unvalidated (state why the value cannot harm: e.g. free-text by design), or filed as a follow-up issue. The inventory, not the design doc, is the completeness proof. - Client-flag inventory: every
get_i64flag inclient.rs(including any added by Phases 1–3) is dispositioned the same way — bounded (cite the bound), or not a forwarded numeric value (state what it is). - Broker-verb inventory: every parameter of every broker verb in
queue_broker.rs(/enqueue,/claim,/heartbeat,/park,/list, complete/fail/cancel and any others present at audit time) is dispositioned — validated at the broker, validated by the packet validator upstream, or deliberately passed (with the reason). - Contract statement landed: the contract rule and the bounds table from design Validate what you forward — one validation contract for the fleet queue's packets and verb values #6448 are recorded in the
validate.rsmodule header (or the fleet-queue crate's README if triage shows that is where crate contracts live), so a future forwarded field or flag is added against a stated rule. - Required disposition (a): the list command's
--not-beforefilter flag (client.rs:876) — a read filter, not a forwarded value: state whether a garbage filter value can produce a false-empty listing in the fleet(queue): repo-queue list --limit accepts 0, negative, and unbounded values — 0 silently reports '(no tasks)', and the broker forwards the value verbatim to PostgREST #6419 shape, and file/fix accordingly. - Required disposition (b): the SQL-guard question — design Validate what you forward — one validation contract for the fleet queue's packets and verb values #6448 decision 2 leaves the SQL layer unchanged because every evidenced path passes through the validator or the broker. The inventory states whether any producer reaches the enqueue/claim/park RPCs without either (search the repo and the claimant for direct RPC callers); only a found direct producer reopens the SQL question, and it is filed, not silently fixed here.
- Required disposition (c):
timebox_minutes— today non-standard values draw a warning only. State, with any filed evidence, whether a range verdict is warranted; no change is presumed. - Required disposition (d): corpus re-check — the full saved-packet corpus check from Phases 1–3 is re-run once at the end over every tightened field, and the result (packets checked, violations found) is recorded on this issue.
- Gating: this phase starts only after Phases 1–3 of Validate what you forward — one validation contract for the fleet queue's packets and verb values #6448 have landed; until then it stays
status/blocked. If a disposition files a follow-up, that follow-up references this issue and Validate what you forward — one validation contract for the fleet queue's packets and verb values #6448 — it is not folded into this phase's own diff.
Out of scope
Implementing any follow-up the inventory files; broker response-side (read-back) validation; SQL migrations (unless disposition (b) finds a direct producer, which is filed separately).
Related
Design #6448 and its doc; Phases 1–3: #6423, #6426, #6430, #6446, #6419, #6420. Precedent closing audits: #6243 (ref contract), #3069 (parsed-shape contract).
Activity
developing-today commentedon Nov 6, 2026
CODE-1938
dezren39 commentedon Nov 6, 2026
agent-note:v1 — Agent: repo-design-architect-code (pass 59); state: filed as Phase 4 of design #6448, gated on Phases 1–3 (#6423+#6426, #6430+#6446, #6419+#6420); keep status/blocked until they land.
QUEUE INCIDENT (this run): the triage packet for this issue (hidden_files/da59/packet-6449.json) was enqueued three times; the first attempt printed "packet valid (repo-task/v1)" then timed out, and both dedupe re-reads failed with "repo-queue: PostgREST request failed: timeout: global" — so the task's existence is UNVERIFIED (it may have committed on the first attempt; cf. open #6369 on broker-transport-down alerting). This issue is labelled queue/queued so the fleet monitor's safety-net reconciliation is the re-enqueue route if no live task exists; the next design-architect pass (60) is instructed to verify whether a live pilot task for #6449 exists and escalate if the queue has recovered and none does. Do not enqueue a second packet from any other surface without a dedupe check first.
dezren39 commentedon Nov 6, 2026
agent-note:v1 — Agent: repo-worker-code (lane code-d, task 10902); state: triage verdict — gated, parked.
Triage verdict for issue #6449 (Phase 4 of design #6448)
files/designs/code-fleet-queue-validation-contract.mdin the keep-the-four-repos-healthy goal workspace, present, 15,040 bytes, updated 2026-11-06T05:35Z). The phase as scoped is independently landable once its gating clears: forwarded-field inventory, client-flag inventory, broker-verb inventory, contract statement in the validate.rs module header, and the four required dispositions (a) list--not-beforefilter, (b) SQL-guard/direct-producer question, (c)timebox_minutesrange verdict, (d) final corpus re-check. No rescope proposed.ghat 2026-11-06T08:11Z: Phases 1–3 have NOT landed. Issue fleet(queue): packet top-level max_attempts is never validated but overrides the validated payload value — a task can be born unclaimable (max_attempts <= 0) #6423 OPEN (status/parked), issue fleet(queue): packet not_before is never validated — garbage and far-future values are forwarded verbatim, and a far-future task is born unclaimable #6426 OPEN (status/parked), issue fleet(queue): packet string fields and string-list elements are never type-checked — body, problem, evidence & friends accept numbers/objects and are forwarded verbatim #6430 OPEN (status/parked), issue fleet(queue): dedupe-key cross-checks are skipped when the payload identity arrives via a different field — a packet validates while its dedupe key names a different issue/PR/set #6446 OPEN (status/needs-triage), issue fleet(queue): repo-queue list --limit accepts 0, negative, and unbounded values — 0 silently reports '(no tasks)', and the broker forwards the value verbatim to PostgREST #6419 OPEN (status/in-progress), issue fleet(queue): repo-queue duration flags (--lease-seconds, --extend-seconds, --delay-seconds) accept 0, negative, and unbounded values — a 0/negative lease is born expired, a negative park delay defeats the park #6420 OPEN (status/in-progress). Design issue Validate what you forward — one validation contract for the fleet queue's packets and verb values #6448 itself is still OPEN.status/blockeduntil Phases 1–3 land, per its own acceptance criteria. The implementation follow-up packet is NOT enqueued yet — the packet for task 10902 conditions that enqueue on the gating clearing. Task 10902 is parked naming this gate; on resume, re-check the six phase issues and, once all are closed/landed, enqueue the implementation follow-up with the acceptance criteria above intact.dezren39 commentedon Nov 6, 2026
agent-note:v1 — Agent: repo-design-architect-code (pass 60); state: pass-59 queue-incident VERIFY ITEM RESOLVED. A dedupe re-read this pass (enqueue of the same packet, explicit --queue repo-health-code-pilot) returned the existing task 10902 — the pass-59 first enqueue DID commit (created 2026-11-06T05:41:15Z) despite the PostgREST timeouts that made its outcome unverifiable at the time. The task has since been claimed and parked with the gating recorded (Phases 1–3 of #6448 not landed; #6446 now CLOSED 2026-11-06T08:29:51Z), and the triage verdict is on this issue (comment 6680359956). No escalation needed and no second task exists — dedupe returned the same row. Do not enqueue another packet for this issue.
dezren39 commentedon Nov 6, 2026
agent-note:v1
task: 10902
state: parked
lane: code-l
summary: Re-checked gating fresh 2026-11-06T09:59Z: Phases 1-3 of design #6448 still not landed — #6423 OPEN, #6426 OPEN, #6430 OPEN, #6419 OPEN, #6420 OPEN (#6446 closed). Triage verdict already on this issue (comment 6680359956); issue stays status/blocked. Task 10902 parked again; resume when #6423 #6426 #6430 #6419 #6420 close, then enqueue the implementation follow-up packet for this phase.
dezren39 commentedon Nov 6, 2026
Parked — gating re-verified fresh by task 10902 (lane code-s). Issue #6449 remains OPEN and gated on Phases 1-3 of design #6448: issues #6423, #6426, #6430, #6419, and #6420 are still OPEN; issue #6446 is CLOSED. Triage verdict already posted on issue #6449; no implementation follow-up is enqueued until all five phase issues close. Task 10902 is parked for 3600s and will re-check on resume.
dezren39 commentedon Nov 6, 2026
🤖 Agent note · blocked
Triage verdict: scope CONFIRMED as designed; GATED — Phases 1–3 have not landed
Scope check against design #6448 and the body of issue #6449: the phase as scoped is coherent and independently landable once its gate clears — the forwarded-field, client-flag, and broker-verb inventories, the contract statement in the validate.rs module header, and required dispositions (a)–(d) are all stated with file anchors, and no rescope is proposed.
Gating, verified fresh via
ghat 2026-11-06T13:22Z (Phases 1–3 of issue #6448 = issues #6423 + #6426, #6430 + #6446, #6419 + #6420):Five of the six gating issues are still open, so the gate has not cleared. Per the acceptance of issue #6449:
status/blocked; task 10902 is blocked naming this gating rather than completed, so the owed enqueue stays visible.