P0: Compaction failure repeatedly blocks Sessions and is mislabeled as a model-provider error #151

Evidence and scope

Based on a private support handover dated 2026-10-02 and a follow-up report dated 2026-10-06. Customer identities, deployment coordinates, project paths, session identifiers, and raw attachments are deliberately omitted. Code references are pinned to current public master (3f90286), not the reporter's deployed build or uncommitted local changes. Production was not accessed or modified during this triage.

Impact

Support recorded four failed Runs for one long Session and reports another blocked Session on October 6. Users receive an error instead of an answer and have to wait for support. The displayed message starts Model provider request failed even when the underlying failure is Compaction did not create .

Code evidence

• Threshold-triggered compaction before the task model request can re-enter compaction while the old context remains over threshold.
• Prompt catch path feeds non-provider exceptions to normalizeModelError.
• Model error normalization falls back to Model provider request failed for unknown errors.
• Handoff prompt deliberately stops task work; its internal messages must not look like the actual response to the user's task.

Fixing the storage conflict (#150) is necessary but does not cover future storage faults, invalid summaries, aborts, or failed compaction retries.

Required behavior

• Record a distinct compaction failure outcome and retain the original context, accepted user intent, and Project work.
• Bound retries within a compaction attempt and across subsequent prompts; do not enter an automatic failure loop on every message.
• Offer explicit retry and a safe authorized continuation/recovery path. If context cannot fit safely, say so rather than blindly skipping compaction or silently dropping history.
• Keep internal compaction text/events distinguishable from task output.
• Classify compaction/storage, authorization, and genuine model-provider failures separately in durable events and UI; avoid leaking internal paths to ordinary users.
• Use existing Session/Run authority; no transcript rewriting or parallel frontend truth store.

Existing-session recovery

Provide an operator/user procedure that preserves existing work. A previously written Project summary can be used only as historical evidence: verify actual files and Git diff, treat old CONTEXT HANDOFF MODE text as history rather than current instructions, and do not automatically commit support/QA artifacts. A new chat is not a guaranteed fix for shell/policy faults and should not be the only recovery option.

Acceptance

• Inject failed persistence and an invalid summary into a long restricted-user Session; original history and work survive.
• Repeated prompts cause no unbounded automatic compaction retries or tool-call loop.
• User sees a localized compaction failure with an actionable recovery choice, not a provider outage.
• Cancel/restart/reconnect/retry remain consistent and do not duplicate accepted intent or task effects.
• Recovery from an existing authorized summary continues work without restarting implementation from scratch.
• True provider failures still retain their proper classification.

Translations must cover en/de/es. New incident diagnosis still requires an authorized, redacted Run trace; the screenshot alone does not establish its precise cause.