fb4b218e450245ddbb533caa3e100374a596ca2d
Wurde ein Chat abgebrochen, waehrend ein Werkzeug lief, blieb im Kontext eine assistant-Nachricht mit tool_calls stehen, auf die keine Antwort folgte. Diese Folge lehnt die Schnittstelle mit HTTP 400 ab - der Agent war danach nicht mehr ansprechbar. Der Schaden wurde dabei dauerhaft gemacht: Jeder catch-Block ruft AddChatEntry, das ruft PersistChatState, und das schreibt den Kontext atomar auf die Platte. Das atomare Schreiben war hier keine Rettung, sondern die Garantie, dass die kaputte Fassung heil ankommt. Ein Neustart half nicht, weil LoadPersistedChats sie zurueckholte. Ausloeser war durchweg Normalbetrieb: AbortChat durch den Benutzer, LoopGuard.Timeout, oder eine Instanz, die waehrend eines Werkzeuglaufs geordnet herunterfaehrt. Die Antworten gehen jetzt aus einem finally raus. Auf jedem Ausgangspfad bekommt jeder Aufruf seine Antwort, bei Abbruch eine Ersatzantwort, die auch sagt, was passiert ist - eine leere waere formal gueltig, liesse das Modell aber raetseln. Zwei Tests: einer auf die Form des Kontexts, einer auf das, worauf es ankommt - dass ein zweiter Chat danach wieder durchlaeuft. Der erste schlug vor der Behebung fehl. 543 Tests in Core, keine Regression. Build ohne Warnungen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Description
No description provided
14 MiB
Languages
C#
84%
JavaScript
10.3%
HTML
3.3%
CSS
1.3%
Python
1.1%