A dropped retry made V2 fail silently on truncated model output

Summary: A long response hit the max_tokens cap and was truncated mid-JSON, so parsing raised. V2 — unlike V1 — had no retry and posted no message, so the session just went quiet. The fix is to retry the parse and always surface failure to the user.

What was encountered

A long DraftResult hit max_tokens=4096 and got truncated mid-JSON, so model_validate_json() raised. V2's FastAPI handler caught it, rolled the status back, and posted nothing — from the engineer's side the bot simply stopped responding. V1's CLI had retried a bad parse at temperature=0.3, so the "newer" V2 was actually less robust than V1 on the same failure.

How it was solved

Three moves: retry the parse (temperature 0.3, as V1 did) before giving up; if it still fails, post a comment so the human knows to retrigger — never fail silently; and attack the trigger by raising/limiting max_tokens or detecting truncation and continuing generation.

Reference: Graceful degradation — retries and visible failure are exactly the concept, and a rewrite quietly dropped both. Related: a schema gives a clean failure signal but not a failure policy — see validating every phase into a schema.