fix(cli): a provider failure leaves the CLI as one line, and a guessed base id is correctable

Funn 99, measured offline against the artefacts the paid Q5=B run left behind — no paid
run here.

ROOT, verbatim from the records: the three failing quick_validate calls all sent
bundle_id="renholdstekniske_funksjonskrav" — a CONCEPT name guessed out of the seeded cut,
while the base's id is k2-trinn1-20260903. Both arguments parsed against the signature, so
it was _resolve_bundle's raise MAF counted, proven by quick_validations being EMPTY while
all three stand in tool_calls. Denominator: 12 tool calls, and those three came BEFORE
list_bundles.

The order's causal chain is FELLED: the quick_validate triple is records 4-6 and the run
continued for 13 more model calls; the triple immediately before the 400 is the navigator's
three read_file refusals on del-ii-bilag-7-prisskjema*. The limit fired TWICE.

(A) ChatClientException is caught on BOTH seams — the exploration dispatch and the full-run
dispatch — because the debate's own model calls go through the same provider. The line is
"run stopped:", not "run refused:" (a stated divergence from the order): the argv was fine
and tokens were already spent, which is the MAJOR-2 arm's own reason, verbatim. Caught
INSIDE the try/finally so the exploration artefact still lands.

(B) quick_validate answers an unknown base id with {"decision": "refused", ...} naming the
configured ids, and records it in the sink. MAF turns a tool raise into the opaque
"Error: Function failed." (_tools.py:1426), so the one thing the refusal knew and the model
did not never reached it — the replies show it guessing at the JSON format instead.
read_file/read_dir/read_bundle still raise: measured, reported, out of scope.

Seven mutations all red against the whole suite, green control 1529/5, golden ea8c534
unchanged. One existing gate REWRITTEN, not deleted; its second half is what keeps (B)
scoped. The test double raises from the reply_selector seam rather than a new
_inner_get_response body, so the S2.5 consolidation guard stays untouched.

Co-Authored-By: Claude <claude-opus-5>
This commit is contained in:
Kjell Tore Guttormsen 2026-09-08 21:03:18 +02:00
commit 078a099898
5 changed files with 543 additions and 5 deletions

View file

@ -0,0 +1,190 @@
# Funn 99 — `ChatClientException` forlot CLI-en som traceback
**Dato:** 2026-09-08 · **Ordre:** `20260908T180612Z-6878816140-from-.claude` · **HEAD før:** `4f23fa2`
Ingen betalt kjøring. Alt under er målt offline mot artefaktene den betalte Q5=B-kjøringen
etterlot (`scratchpad/q5b/live/`, økt 99) og mot MAF-kilden i `.venv/`.
MAF: `agent-framework-core` **1.16.0**, `agent-framework-orchestrations` **1.1.1** (`uv.lock`).
Remote målt: `git ls-remote origin main` = `4f23fa2` = HEAD → **UPUSHET = 0** (STATE-ens «3» var
foreldet og er rettet).
---
## 1. Målingen
### 1.1 De tre feilende `quick_validate`-kallene, ORDRETT
Fra `scratchpad/q5b/live/outbox-Bseed/q5b-Bseed-exploration.json` (`tool_calls`, i kall-rekkefølge)
og fra argument-blobbene i `Bseed-records.json` record 7:
| # | `bundle_id` | `proposal_json` | Hva MAF la tilbake |
|---|---|---|---|
| 1 | `renholdstekniske_funksjonskrav` | `{"cost_saving_direction":"Implement a comprehensive system integration and coordination strategy under a dedicated Responsible for IT and Building (RITB) role …"}` | `Error: Function failed.` |
| 2 | `renholdstekniske_funksjonskrav` | `{"cost_saving_direction":"Implement a dedicated Responsible for IT and Building (RITB) role …","rationale":"General technical requirements highlight …"}` | `Error: Function failed.` |
| 3 | `renholdstekniske_funksjonskrav` | `{"cost_saving_direction":"Assign a dedicated RITB role to coordinate system integration …","rationale":"General technical requirements advise dedicated roles (RITB) …"}` | `Error: Function failed.` |
**Roten: ukjent base-id.** Basens ekte id er `k2-trinn1-20260903`;
`renholdstekniske_funksjonskrav` er et KONSEPT-navn modellen gjettet ut av det seedede kuttet.
Begge argumentene var strenger og parset mot signaturen `quick_validate(bundle_id: str,
proposal_json: str)` — MAF feilet altså **ikke** på argumentformen. Det som feilet var
`_resolve_bundle`s raise (`src/portfolio_optimiser/explore.py:898-900`, `ExplorationError`).
**Beviset på at det var raisen og ikke et verdikt:** `quick_validations` i artefaktet er **tom**,
mens alle tre kallene står i `tool_calls`. Sinken appendes på HVER verdikt-gren
(`unparseable` / `rejected` / `validated`), og bare raisen gikk utenom. Ordrens premiss (ii)
er dermed bekreftet.
**Nevner:** 12 verktøykall totalt i kjøringen —
`read_file` 5 · **`quick_validate` 3** · `read_dir` 2 · `list_bundles` 1 · `read_bundle` 1.
Alle tre `quick_validate`-kallene er kall **0, 1 og 2**, altså FØR `list_bundles` (kall 3):
modellen gjettet en base-id før den noen gang spurte hvilke som fantes.
### 1.2 MAF-tellingen
- `.venv/…/agent_framework/_tools.py:1410-1432``_function_execution_error_result`: en raise i
verktøyet blir `Content.from_function_result(call_id=…, result="Error: Function failed.",
exception=str(exception))`. Detaljen er **undertrykt** med mindre `include_detailed_errors`
(linje 1427). **Et raise TELLER altså som «error» — svar på ordrens spørsmål.**
- `_tools.py:1895-1900``had_errors` er sann når et `function_result` bærer `exception`.
- `_tools.py:2718-2731``_update_consecutive_error_count`; grensen er
`DEFAULT_MAX_CONSECUTIVE_ERRORS_PER_REQUEST = 3` (`_tools.py:96`).
- `_tools.py:2856-2869` — ved grensen appendes `Message(role="tool", contents=execution_results)`
og `action="stop"`.
- `_tools.py:3303-3305` — «stop» betyr **`options["tool_choice"] = "none"` og så ett kall til**;
det er dét MAF sender etter grensen.
### 1.3 Ordrens ÅRSAKSKJEDE er FELT av målingen
Ordren leste kjeden som «tre `quick_validate`-feil på rad → grensen → resultat uten kall → 400».
**Records viser noe annet.** `quick_validate`-trippelen er records 4-6; kjøringen fortsatte
etterpå gjennom 13 modellkall og 9 verktøykall til. Trippelen som ligger UMIDDELBART foran 400-en
er en helt annen — navigatørens tre siste kall, ordrett fra record 19s prompt:
```
ok {"bundle_id":"k2-trinn1-20260903","path":"…/1-1"}
ok {"bundle_id":"k2-trinn1-20260903","path":"…/1-1/03-01-2023-vask-av-layout.md"}
ERR {"bundle_id":"k2-trinn1-20260903","path":"inbox-del-ii-bilag-7-prisskjema.md"}
ERR {"bundle_id":"k2-trinn1-20260903","path":"del-ii-bilag-7-prisskjema"}
ERR {"bundle_id":"k2-trinn1-20260903","path":"del-ii-bilag-7-prisskjema.md"}
```
Grensen fyrte altså **to ganger** i kjøringen, og 400-en kom på det NESTE agent-kallet
(record 19, hypothesiser), ikke på kallet rett etter `quick_validate`-trippelen.
### 1.4 «Resultat uten kall» — MAF-defekt eller po?
**IKKE VERIFISERT, rapportert som hypotese med linjer.** Feilen er
`400 … 'No tool call found for function call output with call_id call_AyeuYJmqvmmej9utu361Phtt.'`
— Responses-APIet fant et `function_call_output` uten sitt `function_call` i input.
Den ene mekanismen jeg KAN peke på i kilden er
`agent_framework_openai/_chat_client.py:1557-1559`: under service-side storage DROPPES
`function_call`-items fra inline input (`case "function_call": if request_uses_service_side_storage:
continue`), mens `function_result` sendes videre (kommentar :1540-1542, «plain function_call_output
pairs by call_id and is safe under storage»). Den parringen holder bare så lenge serveren HAR det
matchende kallet.
Hvorvidt det er dét som brast her er **ikke målt** — det ville krevd en ny betalt kjøring, som
ordren forbyr. Ingenting i `po` konstruerer meldinger på denne stien; po leverer et verktøy som
raiser, og MAF eier både konverteringen og transporten. **Fikset ALDRI i MAF.** Rapportert her.
---
## 2. Beslutningen
### (A) CLI-døren — JA, og på TO sømmer
`ChatClientException` (fra `agent_framework.exceptions`, ALDRI bar `Exception`) fanges nå
1. i utforsknings-dispatchen (`run.py`, samme blokk `BudgetExceeded` ble lagt til for), og
2. i fullkjørings-dispatchen (`run_project`) — debattens egne modellkall går gjennom samme
leverandør, så en fiks på bare den ene lar en helt vanlig `run.main([...])` tracebacke.
**AVVIK fra ordren, uttalt:** ordren ber om linjen `run refused:`. Levert er **`run stopped:`**.
Grunnen er repoets egen etablerte kontrakt, sitert ordrett fra `run.py`s MAJOR-2-arm:
«the argv was fine and the run had already spent tokens, so "refused" would mislabel it».
En leverandør-400 midt i en utforskning er ikke en argv-feil; `run refused:` ville sagt at po
avviste bestillingen. Klassen er dét som ruter den, akkurat som for `ProposalReviewInputError`.
Er PM uenig, er endringen én streng på to steder.
Artefaktet overlever: armen står **INNE i** try/finally, så `finally`-en fortsatt skriver
`{run_id}-exploration.json` med `completed: false`. Målt, ikke antatt (T3).
### (B) Verktøyet — JA, og kun for `quick_validate`
Målingen i 1.1 viser at det VAR `_resolve_bundle`s raise som ble telt, altså er ordrens betingelse
oppfylt. `quick_validate` returnerer nå
`{"decision": "refused", "reason": "unknown knowledge base 'X'; configured: Y", "anchored": false}`.
Hvorfor: MAF gjør raisen om til den ugjennomsiktige `"Error: Function failed."`, så **den ene
tingen refusalen visste og modellen ikke — hvilke id-er som finnes — nådde den aldri.** Følgen står
i modellens egne ord (record 5): «It appears the quick validation function is failing, possibly due
to format or content expectations» — den gjettet på JSON-formatet, som var riktig hele veien.
`anchored: false` er et faktum, ikke en default: ingen base ble resolvert, så ingen
`cost-baseline.json` ble lest.
**«Ikke i sinken» er OPPHEVET, med begrunnelse.** Kommentaren i koden var skrevet for en RAISE, som
etterlot null verdikt. Nå FINNES det et verdikt, og sinkens egen regel er «hver gren». Å holde det
ute ville gjort en refusert forespørsel til det ene `quick_validate`-utfallet som er usynlig i
`quick_validations` — og det er nøyaktig hvorfor denne økta måtte lese TO artefakter for å finne
roten.
**Scopet er smalt med vilje:** `read_file` / `read_dir` / `read_bundle` raiser fortsatt, og deres
raises telles på nøyaktig samme måte (se 1.3 — det var DEN trippelen som lå foran 400-en). Å endre
dem er en egen beslutning, ikke en jeg tar under en ordre som scoper (B) til `quick_validate`.
**MÅLT, RAPPORTERT, IKKE FIKSET.**
### Ikke gjort, og hvorfor
- **Ingen retry-logikk** (ordren forbyr).
- **Ingen ny `max_consecutive_errors_per_request`** — jeg har ingen måling som viser at den hjelper.
- **Ingen skjuling av andre unntakstyper** — begge armene er nøklet på klassen, og hver av dem har
en kjent-negativ arm som blir rød når den utvides til `Exception`.
- **`include_detailed_errors`** er IKKE skrudd på. Det ville sendt po sine feiltekster videre til
modellen på alle fire verktøy og er en flate-endring, ikke en fiks.
- **Hostet flate BEVISST urørt** — feltet er ikke i noen av hostings tre sett, og Fase 4es to
halvdeler står (MAJOR-4/S7bs eget valg gjentatt).
---
## 3. Load-bearing MÅLT
Ny fil: `tests/test_run_cli_chatclient_refusal.py`, 8 armer.
Grønn kontroll **1529 passed / 5 skipped**, golden `demo-transcript.stdout` BYTE-UENDRET
(`shasum -a 1` av INNHOLDET = `ea8c534773acdbe41ae68f2c55724d69aaf8be4f`, aldri git-blob-id-en).
Sju mutasjoner, ALLE RØDE mot HELE suiten:
| # | Mutasjon | Røde |
|---|---|---|
| M1 | detach utforsknings-armen | 2 (T1 + T3) |
| M2 | utvid utforsknings-armen til `Exception` | 5 — hvorav **4 i tester eldre enn dette arbeidet** |
| M3 | detach fullkjørings-armen | 1 (T4 ALENE — T1 grønn, altså er sømmene uavhengig gatet) |
| M4 | utvid fullkjørings-armen til `Exception` | 4 — hvorav 3 eksisterende, uavhengige vitner |
| M5 | gjeninnfør raisen i `quick_validate` | 3 |
| M6 | refuser ubetinget | 3 — hvorav 2 eksisterende (kontrollen er ekte) |
| M7 | dropp sink-appenden på den refuserte grenen | 1 (T8 ALENE) |
**T3 har ingen egen mutasjon, og det står som en ærlighets-grense.** Den pinner ordrens krav om at
allerede skrevne records overlever nekten, men `finally` kjører også ved `return` fra en `except`,
så enhver plassering av armen inne i funksjonen ville bestått den. Den er rød sammen med T1 under
M1 og ellers ikke separabel.
**En eksisterende gate ble SKREVET OM, ikke slettet:**
`test_explore_loadbearing::test_an_unknown_knowledge_base_is_refused_by_name` pinnet raisen.
Egenskapen den ble skrevet for — «refuserer, og sier hva som ER konfigurert» — er urørt og
assertert i begge halvdeler; den nye andre halvdelen driver `read_file` og er dét som holder
(B) SCOPET til `quick_validate`.
**Testdoblen fikk INGEN ny `_inner_get_response`-kropp.** Første utkast gjorde det og felte
S2.5-konsolideringsvakten (`test_scripted_client_consolidation`). Raisen bor nå i
`reply_selector`-sømmen, som den kanoniske kroppen kaller SYNKRONT (`simulation.py:443`) før den
bygger noen koroutine — samme punkt en ekte leverandørfeil ville truffet, og vakten forblir
urørt i stedet for utvidet.
---
## 4. Kommandoen som viser nekten (gratis)
```
uv run pytest tests/test_run_cli_chatclient_refusal.py -q
```