fix(timmy): stop SSE streams being cut at the server write timeout

[ericfitz]

The problem

tmi-ux reported net::ERR_HTTP2_PROTOCOL_ERROR on POST /threat_models/{id}/chat/sessions/{id}/messages. Timmy answers appeared truncated in the browser while the server logged 200 with no error.

http.Server.WriteTimeout bounds the entire response write, and Go arms that deadline when the request header is read — not per write. cmd/server/main.go:2106 applies it unconditionally and the default is 10s, so any SSE stream living longer has every subsequent write fail with i/o timeout. Silently: the handler keeps producing events into a dead socket, returns normally, and the request logger records 200. The browser only learns anything is wrong when the connection closes abruptly at handler return.

Measured against the AWS deployment, driving the real client origin

last byte received	10,055 ms — the 10s timeout, to within 55 ms
error surfaced	25,761 ms — handler return, connection closed
silent gap	15,706 ms
message_end	never

That 15.7s gap is also wasted LLM spend: tokens generated and billed for a client that stopped receiving at 10s.

It explains the whole symptom set. Streams under 10s always worked — a 1.8s message and a 1.2s session create both completed — which is why this looked intermittent rather than systematic, and why one observed 9.8s session create survived by 0.2s. Session creation emits progress events continuously and finishes fast; a message goes quiet while the model thinks and then streams a long answer, so it is the one that reliably crosses the line.

The fix

Clears the write deadline for the response via http.NewResponseController. That needed a second change: gin.ResponseWriter is an interface that does not declare Unwrap, so bufferedResponseWriter (which JSONErrorHandler wraps every response in) promoted no Unwrap and the controller stopped there with ErrNotSupported — the clear would have compiled, run, and silently done nothing.

Second commit: stop paying for tokens nobody receives

All 11 SendEvent/SendToken/SendError call sites discarded their error with _ =. IsClientGone could not have caught this either — it only checks request-context cancellation, and a failed write does not cancel the context.

The writer now latches the first write failure and IsClientGone reports it alongside cancellation. The token callback cancels the LLM context when it trips: returning early only stops us writing, while generation continues. The LLM context is deliberately detached via context.WithoutCancel (so a 30s request deadline cannot cap a 120s inference), which makes that callback the only thing that can end generation early.

Also

Removes c.Header("Connection", "keep-alive") from the SSE writer. Unrelated to this bug — I confirmed session-creation streams carrying the same header complete cleanly over HTTP/2 — but it is redundant on HTTP/1.1 and RFC 9113 §8.2.2 forbids connection-specific header fields in HTTP/2.

Verification

A test streams past a deliberately short WriteTimeout through the real middleware stack. Against the old code it fails the same way production did: stream broke mid-flight after 5/12 tokens (sawEnd=false): unexpected EOF, where 5 tokens × 60 ms is the 300 ms deadline. A second test fails writes while leaving the request context live — the exact condition the old code could not detect — asserting the failure latches, IsClientGone flips, and five further sends make zero additional write syscalls.

lint 0 · 2422 unit tests

🤖 Generated with Claude Code

https://claude.ai/code/session_01WnrVyySuyJFqcMxB8q3pNc