chore(registry-dash): SSE frame logging to diagnose AI tool-pill loss (SRE-1963)#143
Closed
UDtorrey wants to merge 1 commit into
Closed
chore(registry-dash): SSE frame logging to diagnose AI tool-pill loss (SRE-1963)#143UDtorrey wants to merge 1 commit into
UDtorrey wants to merge 1 commit into
Conversation
… (SRE-1963) PR #141 was supposed to make tool pills persist in the chat scrollback, but on alpha they still vanish: pills appear IN_FLIGHT during execution, then by the end of the response no pills remain (and turn-0 / turn-1 assistant text gets concatenated with no per-turn split). Backend GCP logs (ud-registry-alpha-gke, k8s_container) confirm the orchestrator emitted ToolUseEvent + ToolResultEvent for every tool call — so the SSE wire definitely carries the frames; the frontend loses them somewhere. Static analysis of ai-analysis.service.ts couldn't pinpoint the failure path. The frontend has no logging, and the SSE handler's catch block silently swallows every parse error, so any code change is currently a guess. Add minimal diagnostic surface so the next repro on alpha tells us which of three failure modes is real: - console.warn on the previously-silent catch — surfaces JSON.parse failures and the offending payload (e.g. chunk-boundary truncation or unexpected bytes in `args`). - console.debug at the dispatch entry — prints the type + tool/status of every frame the frontend actually sees, in order. Cross-referenced against the GCP turn-by-turn tool log, this immediately shows whether frames are being dropped, mis-typed, or fully arriving but lost downstream (state mutation or render). No behavior change. Once the diagnostic points at the actual failure mode the fix will be one targeted change; the console.debug should be removed at that point and the console.warn left in as a permanent guardrail for future SSE parse regressions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PR #141 was supposed to make tool pills persist in the chat scrollback, but on alpha they still vanish: pills appear IN_FLIGHT during execution, then by the end of the response no pills remain (and turn-0 / turn-1 assistant text gets concatenated with no per-turn split).
Backend GCP logs (
ud-registry-alpha-gke,k8s_container) confirm the orchestrator emittedToolUseEvent+ToolResultEventfor every tool call across every turn — so the SSE wire definitely carries the frames; the frontend is losing them somewhere.Static analysis of
ai-analysis.service.tscouldn't pinpoint the failure path. The frontend has no logging, and the SSE handler'scatchblock silently swallows every parse error, so any code change right now is a guess.What changed
Two diagnostic lines in
console-webapp/src/app/registry-dash/ai/ai-analysis.service.ts. No behavior change.console.warnthe dropped frame and the parse error so chunk-boundary truncation or unexpected bytes inargssurface instead of disappearing.console.debugthe type + tool/status of every frame the frontend actually sees, in order.Cross-referenced against the GCP turn-by-turn tool log we already have, this will tell us instantly whether:
JSON.parse(theconsole.warnwill fire);ng.getComponent(...).aiService.conversationHistory()in the console).In every case the next change is one specific, targeted fix to the actual failure mode rather than a defensive sweep.
Linear: https://linear.app/unstoppable-domains/issue/SRE-1963
Test plan
tscclean (no behavior change; logging only)[ai-chat] frame …and[ai-chat] dropped malformed SSE frame …output and compare to the matching GCP backend turn log for the sessionconsole.debugand ideally keeping theconsole.warnas a permanent guardrail🤖 Generated with Claude Code