Your timing middleware wraps http.ResponseWriter to record the status, and a streaming endpoint under it stops flushing. Why?

## The wrapper a timing middleware needs `ServeHTTP` returns nothing, so middleware that wants to record a status alongside a duration has to interpose on the writer: ```go type statusWriter struct { http.ResponseWriter status int } func (w *statusWriter) WriteHeader(code int) { w.status = code w.ResponseWriter.WriteHeader(code) } ``` Embedding forwards `Header`, `Write` and `WriteHeader` for free and the override captures the code. It looks complete, and for ordinary JSON endpoints it is. ## What embedding an interface actually promotes Embedding a value of interface type promotes exactly the methods **declared in that interface**. `http.ResponseWriter` declares three: `Header`, `Write`, `WriteHeader`. Whatever concrete type sits behind it may also have `Flush`, `Hijack`, `ReadFrom`, `SetReadDeadline` and more — but those are not in the interface's method set, so they are not promoted, and the wrapper does not satisfy the interfaces that name them. That matters because `net/http`'s optional capabilities are discovered by type assertion at the call site: ```go if f, ok := w.(http.Flusher); ok { f.Flush() } ``` Against the real writer the assertion succeeds. Against your wrapper it fails, and the well-behaved `ok` form means the handler does nothing rather than complaining. This is the whole failure: **the capability is lost silently.** ## What that looks like in production A server-sent-events or `text/event-stream` endpoint writes an event and flushes after each one. Under the wrapper the flush is skipped, so bytes accumulate in the connection's buffered writer and are only sent when it fills or when the handler finally returns. From the client's side the stream is dead; from the server's side the handler is running normally and your latency metric is happily counting a request that will take minutes. A WebSocket-style upgrade fails differently and more loudly, since `w.(http.Hijacker)` failing usually ends in a 500. Losing `io.ReaderFrom` costs performance rather than correctness: `io.Copy` falls back to a buffered loop instead of the writer's fast path. ## The modern fix: Unwrap plus http.ResponseController Go's answer is a convention plus a helper. The convention: a wrapper declares ```go func (w *statusWriter) Unwrap() http.ResponseWriter { return w.ResponseWriter } ``` The helper: handlers stop asserting and call ```go rc := http.NewResponseController(w) if err := rc.Flush(); err != nil { // genuinely unsupported, and now you know } ``` `http.ResponseController` walks the chain of `Unwrap` methods to find a writer that supports the operation, so any number of nested middlewares can sit in between as long as each one unwraps. Its methods return an error when the capability is unavailable, converting a silent no-op into something you can log or fail on. It also exposes per-request deadline control, which is the supported way to give one streaming handler a different write deadline from the server-wide one. If you cannot change the handlers — a third-party one, or a library you do not own — the older approach still works: re-declare the methods you must preserve on the wrapper and forward them after a type assertion on the embedded writer. It is verbose, easy to forget one, and exactly the pain `Unwrap` removes. ## The status your timing code records While you are in this code, decide two edge cases explicitly. A handler that only calls `Write` never calls `WriteHeader`, so `net/http` implies 200 and your wrapper's field is still zero — initialise it to `http.StatusOK`, or normalise zero to 200 at record time. And a handler that panics before writing anything leaves the field at zero with the response never completed; recording that as 200 is a lie, so give it its own value in the metric. ## The review rule Any wrapper around `http.ResponseWriter` needs `Unwrap`, and any handler that flushes or hijacks should go through `http.NewResponseController`. It costs one line on each side, and it is the difference between a middleware you can safely add to every route and one that breaks the two routes nobody tested.