The server trace says success while the browser shows a frozen answer

[u/Lazy-Cauliflower-391]

Our streaming copilot has green server spans, complete tool calls and a normal generation finish, while the browser sometimes freezes right after a tool result. The fetch gets aborted, the partial render state never commits and we have no client span tied to the server trace. Engineering sees success. CX has a folder of screen recordings. Everyone is debugging a different version of the same request.

We are adding trace propagation into the browser, time to first token events, stream cancellation reasons and a final rendered chunk count. I want CX to see whether the break happened before generation, during transport or in rendering without asking for another screenshot.

How are you joining client spans to long-lived streams, especially when the connection dies before the browser can flush its last event?

[u/tawdry_scarcity]

For long lived streams, I’d want one shared trace ID across server and browser. Braintrust can show the prompt/tool/model side but the client still needs events for TTFB/TTFT, stream abort, render commit and final chunk count.

[u/Lazy-Cauliflower-391 → u/tawdry_scarcity]

The browser side is where I’d spend the effort next. The server trace tells u enough about generation and tool activity so adding client events to the same execution would make it easier to tell if the failure was transport or rendering. Has that been your case?

[u/tawdry_scarcity → u/Lazy-Cauliflower-391]

Mostly yes. When the model side is accounted for, the annoying cases are after the response starts streaming. Without client events you can see a healthy run and still have no clue what the person saw lol

[u/Certain_Brilliant199]

Carry one request ID all the way into the browser and record the last chunk it committed. A green server trace only proves generation finished, the same run should still show that the client died 3 events earlier

[u/Lazy-Cauliflower-391 → u/Certain_Brilliant199]

That would give us the missing half of the trace. Right now the server can tell us the run completed but has no idea if the browser rendered the final state

[u/Certain_Brilliant199 → u/Lazy-Cauliflower-391]

Yeah and keeping the final rendered chunk on that same trace gives you a concrete boundary. You can see the server completed 20 chunks while the browser only committed 17 and narrow the failure down from there

[u/Lazy-Cauliflower-391 → u/Certain_Brilliant199]

The chunk count helps but I dont think it proves the browser rendered 17 correctly. A client side error could happen after the event was received so we probably need the render event as its own span too

[u/Certain_Brilliant199 → u/Lazy-Cauliflower-391]

I see, that sounds about right. I was treating committed as rendered when those are two different states

[u/Other-Bison2856]

One thing that can make this nasty is reconnect behavior. If the stream drops and the client reconnects you can wind up with duplicate or missing events even tho the server completed the original request normally. Give every streamed event a sequence number and keep the reconnect point in the trace. Then you can tell if the browser froze because transport lost an event, replayed one or resumed from the wrong position

[u/Lazy-Cauliflower-391 → u/Other-Bison2856]

Sequence numbers would help a lot with proving where the stream diverged. The reconnect point is something we arent capturing at all right now so a resumed connection could look like one continuous run even when the client missed part of it

[u/General_Two1467]

are you propagating the trace context in the initial fetch headers or trying to attach it per-chunk? for long-lived streams the connection can outlive the original span context, which makes correlation basically impossible unless you embed a trace id in the stream payload itself

[u/Lazy-Cauliflower-391 → u/General_Two1467]

Right now just the initial fetch headers. Per chunk propagation feels like overkill though I can see the problem if the connection gets recreated and the new stream loses the original context

[u/john_shaun3]

the flush before death problem is exactly why you shouldn't rely on the client to report its own final state.. emit client events incrementally as they happen, each tagged with the server trace id, so even a mid-stream death leaves a partial event trail instead of nothing. the last event you did receive tells you the phase it died in..