fix(claude,web): surface assistant content lost to a mid-stream API retry#6
fix(claude,web): surface assistant content lost to a mid-stream API retry#6Antisophy wants to merge 4 commits into
Conversation
The result event always carries a copy of the final reply text, normally redundant with the streamed assistant message. When the turn's content is lost (e.g. the CLI stops emitting stream events after API retries), that copy is the only surviving record of the reply, yet it rendered collapsed as a bare checkmark divider, indistinguishable from "no response". Compare the result text against the last main-turn assistant message when the result arrives; if it isn't already on screen, flag it and start the result block expanded, like error results already do.
After an API retry, Claude CLI stops emitting stream_event partials for the rest of the process run. Live translation promoted content to visible items only from content_block_* stream events, treating complete assistant events as metadata-only turn/delta, so entire turns rendered as nothing; the final reply text survived only inside the collapsed session-complete result block. When an assistant event arrives and no stream blocks are active, promote its content blocks directly (item/started + item/completed), the same way the sub-agent path already does. Generated item ids use a session-wide counter since per-block assistant events carry no stream index. Also reset stream tracking when an api_retry system event passes through, so a mid-stream abort can't leave stale state that suppresses the fallback.
translateAssistantLive lives on the process-spawning ClaudeCodeSession, so the promotion fallback cannot be driven from a unit test directly. Extract the per-block promotion into a pure static promoteContentBlocks (hoisting the ClaudeBlock parse struct to class scope) and unit-test that a stream-less text block becomes item/started + item/completed and a tool_use block keeps its own id. No behavior change.
The existing result-visibility tests cover the total-blackout shapes (nothing streamed, or streamed text differs). Add the partial case: a thinking block renders while the following text block never streams, so the final reply text is not among the rendered text blocks and the result stays expanded. This is the condition observed in practice, distinct from the total blackout.
|
Rationale for reopening this as a fresh PR: #4 was closed pending a valid test of the condition, and GitHub blocked reopening it once the branch was rebased onto current master, so this supersedes it with the fix unchanged plus that test. Since #4 was closed, the same failure showed up live in a real session: a turn where the thinking block streamed but the following text block's stream events never arrived, so the reply text rendered as nothing and survived only in the result block, which the web layer then kept expanded. That is the partial-stream shape, distinct from the total blackout (nothing streamed) case, and it is likely why an api_retry-only integration test did not reproduce it: the trigger is not limited to api_retry, it is any turn where some content blocks stream and others do not. The new |
1 participant
Supersedes #4 (GitHub would not let me reopen it after the branch was rebased onto current master).
Problem
When the Anthropic API retries a request mid-stream, the Claude CLI can stop emitting
stream_eventpartials for the rest of that run. cydo builds the visible message only from thosecontent_block_*stream events, so when they stop, the assistant turn can end up rendering as nothing, leaving the reply only inside the session-completeresultblock, which itself shows collapsed as a bare checkmark divider, leaving discovery of the full response very unlikely. When it happened to me, the only way I discovered that I actually was receiving responses was through a desktop notification I was lucky to catch when cydo wasn't focused, leading me to click around to try to find the response I'd seen in the notification and finally expand the checkmark divider, which I'd previously dismissed as uninteractive.The gap has two shapes. In the total case, nothing streams and the whole turn is blank. In the partial case, some blocks stream and others do not, for example a thinking block streams while the following text block's stream events never arrive, so the reply text is missing while the thinking is shown. Both leave the final text alive only in the result block.
Fix
Two complementary layers:
fix(claude): promote assistant content when stream events are missing: when a completeassistantevent arrives with no active stream blocks, promote its content blocks straight toitem/started+item/completed(the same way the sub-agent path already does) so the turn renders. Promoted item ids use a session-wide counter (these per-block events carry no stream index), and anapi_retrysystem event resets stream tracking so a half-opened block from the aborted attempt cannot leave stale state that suppresses the fallback. This recovers the total case inline.fix(web): keep session result expanded when its text never rendered: theresultevent always carries a copy of the reply; when that copy is the only surviving record, compare it to the last main-turn assistant message and, if it is not already on screen, start the result block expanded (like error results already do) instead of a bare checkmark. This surfaces the reply in any case the text did not render, including the partial case the backend layer intentionally stays out of because some blocks did stream.Tests
item/started+item/completed, and atool_useblock keeps its own id.result text visibility): covers the streamed-and-redundant, no-message, and differing-text cases, plus the partial-stream shape, a thinking block renders while the text block never streams, so the result text is unseen and the block stays expanded.The partial-stream case is the one seen in practice (a real turn where a thinking block rendered but the reply text did not), distinct from the total blackout, and it is what the web reducer test now pins down.