Skip to content

Task-state compaction never retries a 504 and reports skipped chunks as not degraded #7718

Open

Description

@M3gA-Mind

Summary

Task-state compaction never retries a retryable model error. A gateway 504 on a chunk silently drops that chunk, and the result still reports degraded=false. On a long coding thread, about two thirds of the history reached the checkpoint only as the deterministic ledger.

Problem

Seen 2026-10-12 21:32:53, website thread, mid-turn compression (prompt_tokens=351287 trigger=350000):

  • dispatching task-state compaction … messages=542 chunks=3 approx_input_tokens=277155.
  • Chunk 1 at 21:33:55 and chunk 2 at 21:34:59 each got managed invoke failed: status=Some(504) … retryable=true after ~62 s, then keeping the previous state for this chunk.
  • 21:35:56: task-state compaction complete … chunks_skipped=2 degraded=false.

Root cause (tinyagents crates/tinyagents-harness/src/summarization/task_state/mod.rs):

  • :263-266 self.model.invoke(...).await.map_err(...)?. Any invoke error leaves on the first try. The STATE_ATTEMPTS = 2 loop (:47) only retries markup/JSON parse failures.
  • :344-349: the error is swallowed as "keeping the previous state".
  • :353: degraded = state.is_none(), so skipped chunks are invisible.

OpenHuman sets chunk size (window*2/5).clamp(4_000, 100_000) (agent/tinyagents/harness_context_ladder.rs:280-282). A ~92k-token chunk ran ≥60 s through the managed gateway, which answered 504. The ~60 s limit is inferred from the timings.

Introduced by tinyagents PR #282 / openhuman #6963 (2026-10-03).

Solution (optional)

  • Owner tinyhumansai/tinyagents: retry retryable transport errors (5xx/timeout) inside the attempt loop, and report partial degradation (degraded = skipped > 0 or a partial flag).
  • OpenHuman: lower the managed-route chunk cap (e.g. 40–50k) so one call fits under the gateway timeout.

Acceptance criteria

  • Repro gone — a 504 on a chunk is retried, and a skipped chunk is reported as degraded.
  • Regression safety — a harness test with a model returning a retryable error once.
  • Diff coverage ≥ 80%

Related

#6963.

Activity

  1. self-assigned this
    on Oct 13, 2026
  2. added
    priority: p1Next. Wrong behaviour a user will hit, or a security weakness behind a condition.
    on Oct 13, 2026
  3. tinysweeper commented on Oct 13, 2026

    @tinysweeper

    Task-state compaction's attempt loop only retries parse failures, so a retryable 504 from the managed gateway silently drops the chunk and the run still reports degraded=false, losing most of a long thread's history to the deterministic ledger only. None of the open candidates describe the same defect (they cover memory-budget breakers, transcript discard on stop, tool timeouts, wind-down deadlines, and credential scrubbing), so no prior art is claimed. Broken core compaction path with a partial workaround (lowering the chunk cap), hence p1 rather than p0.

    Labelled priority: p1.

  4. added theissue type on Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

priority: p1Next. Wrong behaviour a user will hit, or a security weakness behind a condition.

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions