A turn whose every model call returned 200 reports the backend as down #715

New issue

Closed

opened 2026-08-13 20:30:00 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 20:30:00 +00:00

Member

Slice of issue 651, acceptance criterion 1 only:

A turn whose model calls all returned 200 never reports model backend unavailable.

That criterion needs no policy call. Criteria 4 and 5 do, and stay on 651.

What happens

A member asked a 53-byte question. The model answered correctly twice, both HTTP 200 in under eight seconds, both outcome: ok from agent-proxy. ValidateNeutralStyle refused both for first-person voice, the repair path exhausted, and the error fell through turnFailureNotice's stage switch to stageModel. The member was told the backend was down.

The fix, and its precedent

turnFailureNotice already carries a case for exactly this shape:

// Ahead of the stage switch, because this happens at the model stage and
// the backend answered every call. See issue 258.
case errors.Is(cause, ErrToolRoundsExhausted):
    return noticeRoundsSpent

Repair exhaustion is the same: model stage, every call answered. A sentinel ErrResponseRepairExhausted and a case beside that one, plus the matching failureCause arm so the label and the phrase keep agreeing as that file documents.

No new member-facing wording. noticeReplyBlocked already exists and already says the true thing. Reusing it is routing, not authoring.

Acceptance

Repair exhaustion carries ErrResponseRepairExhausted, and every model call in the fixture returns 200.
The notice is reply blocked by response check, rephrase, not the outage phrase.
failureCause reports reply_refused rather than stage_failed, which is criterion 3's harness half.
The refusing check still appears in the error text, because naming it is what made 651 diagnosable.
A genuine 503 still reports an outage.
Each row fails under a mutation removing the notice case, in a run where the package compiles.

Next owner

Engineer. Closed by the pull request that lands the change.

Slice of [issue 651](https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/651), acceptance criterion 1 only: > A turn whose model calls all returned 200 never reports `model backend unavailable`. That criterion needs no policy call. Criteria 4 and 5 do, and stay on 651. ## What happens A member asked a 53-byte question. The model answered correctly twice, both HTTP 200 in under eight seconds, both `outcome: ok` from agent-proxy. `ValidateNeutralStyle` refused both for first-person voice, the repair path exhausted, and the error fell through `turnFailureNotice`'s stage switch to `stageModel`. The member was told the backend was down. ## The fix, and its precedent `turnFailureNotice` already carries a case for exactly this shape: ```go // Ahead of the stage switch, because this happens at the model stage and // the backend answered every call. See issue 258. case errors.Is(cause, ErrToolRoundsExhausted): return noticeRoundsSpent ``` Repair exhaustion is the same: model stage, every call answered. A sentinel `ErrResponseRepairExhausted` and a case beside that one, plus the matching `failureCause` arm so the label and the phrase keep agreeing as that file documents. **No new member-facing wording.** `noticeReplyBlocked` already exists and already says the true thing. Reusing it is routing, not authoring. ## Acceptance - Repair exhaustion carries `ErrResponseRepairExhausted`, and every model call in the fixture returns 200. - The notice is `reply blocked by response check, rephrase`, not the outage phrase. - `failureCause` reports `reply_refused` rather than `stage_failed`, which is criterion 3's harness half. - The refusing check still appears in the error text, because naming it is what made 651 diagnosable. - A genuine 503 still reports an outage. - Each row fails under a mutation removing the notice case, in a run where the package compiles. ## Next owner Engineer. Closed by the pull request that lands the change.

coilyco-ops added the

autonomy

headless

label

2026-08-13 20:30:00 +00:00

coilyco-ops referenced this issue from a commit

2026-08-13 20:30:24 +00:00

fix(notice): repair exhaustion is a refused reply, not an outage

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 20:30:24 +00:00

fix(notice): repair exhaustion is a refused reply, not an outage #716

coilyco-ops referenced this issue