Skip to content

Closing queue-validation inventory — disposition every forwarded field, client flag and broker verb value against the validation contract (Phase 4 of #6448) #6449

Open

Description

@dezren39

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 field manual_schema_errors touches 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_i64 flag in client.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.rs module 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-before filter 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

  1. developing-today commented on Nov 6, 2026

    @developing-today
    Contributor
  2. added
    app/fleetpkgs/fleet multicall binary + platform crates
    on Nov 6, 2026
  3. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    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.

  4. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    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)

  5. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    work/assignedQueue worker lifecycle state
    and removed
    queue/queuedHas a queued task in the Supabase agent queue
    on Nov 6, 2026
  6. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    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.

  7. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    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.

  8. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    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.

  9. added
    queue/claimedQueue worker lifecycle state
    and removed
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 6, 2026
  10. dezren39 commented on Nov 6, 2026

    @dezren39
    MemberAuthor

    🤖 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 gh at 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:

  11. added
    queue/blockedQueue or user escalation state
    and removed
    queue/claimedQueue worker lifecycle state
    work/assignedQueue worker lifecycle state
    on Nov 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions