fix(webapp): an unstreamable connection says so instead of going quiet

[ssowonny]

TL;DR

• Collaborative editing was dead on the managed hub, and live change notification with it — but every stream answered 200, so nothing anywhere said so.
• The actual culprit was a middleware in the cloud repo (fixed in beardrive-cloud#42); this is the reason it stayed invisible for as long as it did.
• Both SSE handlers now check flushability before writing a byte, and answer 500 plus a log line naming the cause.
• No behaviour change on a healthy writer.

What went wrong

handleEvents and handleCollabStream both did this:

w.WriteHeader(http.StatusOK)
if err := rc.Flush(); err != nil {
    return // not a streaming-capable writer; nothing to do but leave
}

By the time the question is asked, the 200 and the text/event-stream headers are already on the wire. Returning hangs up, and what the browser receives is a valid, empty, closed stream — so EventSource retries it, forever, without ever firing an error it can distinguish from a flaky network.

On the managed hub that is exactly what happened: an analytics middleware wrapped http.ResponseWriter and implemented neither Flush nor Unwrap, so http.ResponseController could not reach the real writer. Every stream came back:

HTTP/2 200
content-type: text/event-stream
content-length: 0

Live updates delivered no frames. Two browser tabs on one document each edited in their own world, while the POST leg kept answering {"ok":true}. Nothing failed to compile and nothing was logged — it was found by opening two tabs.

The change

refuseUnstreamable walks the Unwrap chain before anything is written, so the answer can be a real 500 and a log line naming the cause:

bdrive: cannot stream /api/p/<id>/events — an http.ResponseWriter in the
middleware chain implements neither Flush nor Unwrap, so live updates and
collaborative editing cannot work

The hub can't repair somebody's broken wrapper. It can refuse to pretend the stream is fine.

The post-header rc.Flush() check stays — a later flush can still fail on a dead connection, which is the case it now describes.

Tests

stream_guard_test.go covers all three states through the real handler:

writer	before	after
middleware with no Flush/Unwrap	200, 0 bytes	500 + log
same, plus Unwrap()	200, 0 bytes	streams normally
plain net/http writer	streams	streams

Each fails without the fix — checked by reverting in a throwaway tree.

Verification

go vet ./... clean. internal/webapp, internal/syncer, cmd/bdrive pass. Playwright e2e 243/243, and the guard never fires there — the harness's writer is flushable, which is the point.

Two notes worth carrying forward:

• Not fixed here: every tab holds a permanent /events stream and every editing tab a second /collab one. On HTTP/1.1 the browser allows six sockets per origin across all tabs, so six browsing tabs — or two editing plus two idle — wedge the whole app, POSTs included. Measured, reproducible, separate change.
• cmd/bdrive/desktop.go's copyFlushing has the same fail-quiet shape, left alone: nothing wraps the sidecar's writer, and it is not on the path this broke.

🤖 Generated with Claude Code