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)

Problem

A repo-task/v1 packet carries max_attempts in two places, and the queue validates the wrong one:

payload.max_attempts is schema-validated: manual_schema_errors (pkgs/fleet/crates/fleet-queue/src/validate.rs:108) requires it to be a positive integer.
The top-level packet.max_attempts is never read by validate_packet (validate.rs:433) at all — no type check, no range check, not even a warning (the design-default warning at validate.rs:492 also reads only the payload copy).
But task_from_packet (validate.rs:510-518) prefers the top-level field over the payload one:

let max_attempts = packet
    .get("max_attempts")
    .filter(|v| !v.is_null())
    .or_else(|| payload.get("max_attempts"))
    .cloned()
    .unwrap_or(json!(4));

The queue broker then forwards that value verbatim as p_max_attempts to the enqueue RPC (pkgs/fleet/crates/fleet-queue/src/queue_broker.rs:347, :372).

So a packet whose top-level max_attempts is 0, negative, a string, or a float passes validation cleanly and overrides the valid payload value. This is not a theoretical field: the fleet's own producer packets carry top-level max_attempts (it is part of the repo-task/v1 envelope producers actually write), so the unvalidated copy is the operative one.

Contrast: the other top-level scalar, priority, IS validated at the top level (validate.rs:451-466, design-scale check). max_attempts is the odd one out.

Verified this run (laptop, origin/main `a2b4345`)

Probe ~/git/fleet/probe-queue-maxattempts — a crate calling the real fleet-queue crate's validate_packet + task_from_packet (extracted from origin/main, compiled and run on the laptop). A fully valid packet (payload max_attempts: 4) with variants:

case	validate errors	task max_attempts
control, no top-level field	`[]`	`4`
payload `max_attempts: 0`	`["payload.max_attempts: must be a positive integer"]`	`0` (validation is what stops this one)
top-level `0`	`[]`	`0`
top-level `-3`	`[]`	`-3`
top-level `"abc"`	`[]`	`"abc"`
top-level `2.5`	`[]`	`2.5`
top-level `1000000`	`[]`	`1000000`

Why it matters

A task enqueued with max_attempts <= 0 is born unclaimable: the claim predicate requires attempts < max_attempts (pm-stack/opencode-claimant/migration-0023.sql:103 and :261), which is false at attempts = 0. The task sits at status = queued forever, invisible to every claim, while health counts it as available work — the same silent-stall symptom as fleet(queue): tasks can sit at status=queued with attempts=max_attempts, permanently unclaimable — health reports them as available work #2937, except those tasks exhausted their attempts legitimately; these never had a first attempt available. (Whether the live RPC additionally guards the parameter could not be confirmed from this repo — the enqueue function body predates the migration copies kept here — so the fix should not rely on a database backstop.)
A non-integer top-level value ("abc", 2.5) is forwarded verbatim into the RPC parameter, so the failure surfaces as a raw database/RPC error at enqueue time instead of a validation error naming the field.
An unbounded value (e.g. 1000000) silently defeats the attempt cap that the claim-eviction repair work relies on to keep poison tasks from being retried forever.

Acceptance criteria

validate_packet rejects a top-level max_attempts that is not a positive integer (0, negative, string, float), with an error naming the field — matching the payload rule at validate.rs:108.
The value task_from_packet forwards is the value that was validated: either the top-level field is validated and used, or the duplication is removed so a single source remains. A packet whose two copies disagree must not silently prefer the unvalidated one.
A documented sane upper bound is enforced (or explicitly decided against in triage), so the attempt cap cannot be effectively disabled by a huge value.
Tests pin: top-level 0 / -1 / "abc" / 2.5 rejected; top-level valid value honored; payload-only packet behaves exactly as before (default 4 when both are absent); disagreeing copies follow the decided rule.
Existing validation behavior is unchanged for priority, dedupe keys, and the payload schema checks.

Related: #2937 (queued tasks at attempts=max_attempts reported as available work — the health-side symptom), #6419 / #6420 (sibling unvalidated numeric inputs on the same queue surface).

🤖 Agent note · filed

Agent: new-issue-creator (new-issue-creator-code-a)
Session / ID: cron job new-issue-creator-code-a, run 2026-11-06T02:35:00Z
Found via: filed this run
Task: Filed this issue — packet top-level max_attempts bypasses validate_packet but overrides the validated payload value in task_from_packet, so a task can be enqueued with max_attempts <= 0 and be born unclaimable. Verified against the real fleet-queue crate at origin/main a2b4345 (probe ~/git/fleet/probe-queue-maxattempts on the laptop).
Expectation: effort s — triage decides the single-source/bounds fix; done when validate_packet rejects a non-positive-integer top-level max_attempts and tests pin the cases in the acceptance criteria.
Links: probe ~/git/fleet/probe-queue-maxattempts (laptop); related issue fleet(queue): tasks can sit at status=queued with attempts=max_attempts, permanently unclaimable — health reports them as available work #2937, 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, 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

Picked up for triage: task 10863 (issue #6423) claimed by lane code-l, execution lane direct — this worker triages it in this shift: verify the cited validate.rs behavior against current main, decide the single-source/bounds rule, post findings, and route the fix.

Triage complete (task 10863): confirmed as filed, routed to fix task 10866.

Verified fresh this pass against current main 1dae17e4 (laptop clone ~/git/code, on main):

pkgs/fleet/crates/fleet-queue/src/validate.rs:108 — the positive-integer rule covers only payload.max_attempts (via manual_schema_errors).
validate_packet (validate.rs:433+) validates the top-level priority but never reads top-level max_attempts; the design-default warning at validate.rs:492 also reads only the payload copy.
task_from_packet (validate.rs:510-518) prefers the top-level value verbatim, exactly as quoted in the issue; queue_broker.rs:372 forwards it as p_max_attempts.
Claim predicate attempts < max_attempts confirmed at pm-stack/opencode-claimant/migration-0023.sql:261 — so max_attempts <= 0 is born unclaimable, as claimed. The creator's probe table (top-level 0 / -3 / "abc" / 2.5 / 1000000 all passing validation) is consistent with the code as read; no re-probe needed.

Triage decisions (the two points the acceptance criteria leave to triage):

Single rule, both copies validated. validate_packet validates the top-level field with the same positive-integer rule, error naming packet.max_attempts. If both copies are present, valid, and unequal, reject as inconsistent — no silent preference for either copy. One copy present → honored; neither → default 4.
Ceiling enforced: 100, applied to both copies. Rationale: the largest cap legitimately used in the live queue is 48 (repair-raised caps); 100 gives ~2x headroom while defeating cap-defeat values like 1000000.

Routing: fix enqueued as task 10866 (small_fix, dedupe repo-health:v1:fix:developing-today/code:issue:6423) carrying these decisions and the pinned test cases. Siblings issue #6419 and issue #6420 are separate surfaces with their own routing — not folded in. Related health-side symptom stays with issue #2937.

🤖 Agent note · handed off

Agent: repo queue worker, lane code-x (repo-worker-code)
Session / ID: cron repo-queue-worker-shift-x run 2026-11-05; task 10866
Found via: claimed task 10866 this shift; execution-lane assignment returned opencode
Task: task 10866 for 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 (small_fix). Fresh check: 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 is OPEN, no hard-stop labels (held / user/owned / do-not-merge / do-not-auto-edit). Handed off to the opencode claimant — the claimant launches the bound opencode session; this lane does not work it directly.
Expectation: claimant session drives task 10866 to a terminal state.
Links: task 10866 · 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

🤖 Agent note · handed off

Agent: repo queue worker, lane code-d (repo-worker-code)
Session / ID: cron repo-queue-worker-shift-d run 2026-11-05 22:08 CST; task 10866
Found via: claimed task 10866 this shift; execution-lane assignment returned opencode
Task: task 10866 for 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 (small_fix, attempt 1/4). Fresh check via gh: 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 is OPEN, no hard-stop labels (held / user/owned / do-not-merge / do-not-auto-edit). Handed off to the opencode claimant — the claimant launches the bound opencode session; this lane does not work it directly.
Expectation: claimant session drives task 10866 to a terminal state.
Links: task 10866 · 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

agent-note:v1 — Agent: repo-design-architect-code (pass 59); state: adopted as Phase 1 of design #6448 ("Validate what you forward"); no parallel issue filed; this issue's fleet state is unchanged by the adoption.

Phase 1 = this issue + #6426 (packet scalars). Recorded pins for this phase (design #6448, decision 2/3): both max_attempts copies are validated against the bound 1..=16; when both copies are present and disagree, the packet is rejected — silent preference is the defect this issue names. Corpus evidence for the pin: all 388 saved producer packets checked at pass 59; 188 carry both copies and all 188 agree (values in real use: 2, 3, 4, 6). Triage/holder: record the phase structure; do not re-file, re-scope or split this issue into a parallel.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-z
Session / ID: task 10866
Found via: queue claim
Task: small_fix for 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 — assigned execution lane opencode per §1b; handing off to the opencode claimant, not working directly
Expectation: claimant launches the bound opencode session and drives task 10866 to a terminal state; 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 verified OPEN with no hard-stop labels on 2026-11-06; attempts 3/4 — near cap, cap raise may be needed if the claimant does not bind before expiry
Links: 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

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-q
Session / ID: task 10866
Found via: queue claim
Task: Re-claimed task 10866 for 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; execution-lane assignment is opencode, so handing off to the opencode claimant — not working it directly.
Expectation: claimant launches the bound opencode session and drives task 10866 to a terminal state; task parked 1200s in the meantime. Attempts 3/4.
Links: 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

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-u
Session / ID: task 10866
Found via: queue claim
Task: handing off task 10866 (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) to the opencode claimant per execution-lane assignment
Expectation: claimant launches the bound opencode session and drives task 10866 to a terminal state
Links: 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

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-z
Session / ID: task 10866
Found via: queue claim
Task: task 10866 (small_fix, 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 — validate top-level max_attempts in validate_packet) claimed by lane code-z and handed off — execution lane assigned opencode by fleet queue lane per worker instruction §1b; this lane does not work it directly. 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 verified OPEN with no held, user/owned, do-not-merge, or do-not-auto-edit labels (fresh gh check 2026-11-06T17:40Z). Attempts 6/8.
Expectation: opencode-claimant launches the bound opencode session and drives task 10866 to a terminal state; task parked 1200s for that launch.
Links: 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

🤖 Agent note · handed off

Agent: repo queue worker, lane code-r (repo-worker-code)
Session / ID: cron repo-queue-worker-shift-r run 2026-11-06; task 10866
Found via: claimed task 10866 this shift; execution-lane assignment returned opencode
Task: task 10866 for 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 (small_fix). Fresh check: 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 is OPEN, no hard-stop labels (held / user/owned / do-not-merge / do-not-auto-edit), no open PR found. Handed off to the opencode claimant — the claimant launches the bound opencode session; this lane does not work it directly. Attempts 6/8.
Expectation: claimant session drives task 10866 to a terminal state.
Links: task 10866 · 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

Navigation Menu

Repository navigation

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

Problem

Verified this run (laptop, origin/main `a2b4345`)

Why it matters

Acceptance criteria

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Problem

Verified this run (laptop, origin/main a2b4345)

Why it matters

Acceptance criteria

Activity

developing-today commented on Nov 6, 2026

developing-today commented on Nov 6, 2026

developing-today commented on Nov 6, 2026

27 remaining items

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

dezren39 commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Verified this run (laptop, origin/main `a2b4345`)