An http.ResponseWriter wrapper logs status 0 for many requests. Why, and how do you fix it?

## The symptom An access-log and metrics layer wraps `http.ResponseWriter`, records `status` and byte count per request, and exports a counter labelled by status. Within a day the dashboard shows a large share of requests with status `0` — a code that does not exist in HTTP — and the latency panel filtered to `status=200` is nearly empty. Nothing is broken on the wire: clients get correct responses. The defect is entirely in the recording. ## Why it happens Two facts collide. **1. `WriteHeader` is optional.** `net/http` sends the status line lazily. If the handler calls `Write` without having called `WriteHeader`, the server sends `200 OK` at that moment and sniffs a `Content-Type` if none was set. If the handler returns without writing anything at all, the server still completes the response with `200` and `Content-Length: 0`. In neither case does `WriteHeader` get called, so the wrapper's override never runs. **2. The zero value of `int` is 0.** `&recorder{ResponseWriter: w}` leaves `status` at `0`. Go has no "unset" for an `int`, and the wrapper cannot distinguish "the handler chose nothing" from "the handler chose zero" unless it says so explicitly. So every handler that takes the implicit-200 path logs `0`. The handlers that *do* log properly are the ones calling `http.Error`, `http.Redirect`, `http.NotFound` or `w.WriteHeader(http.StatusCreated)` — all of which call `WriteHeader` for you. That is why the broken bucket is usually the successful traffic and the correct-looking buckets are the errors, which is the opposite of what you would guess from the dashboard. ## The fix Seed the field with the value the server will actually send: ```go func newRecorder(w http.ResponseWriter) *recorder { return &recorder{ResponseWriter: w, status: http.StatusOK} } ``` One line, no branching, and it is correct because 200 is precisely what `net/http` will send when nobody says otherwise. Force it through a constructor rather than leaving a bare struct literal for the next person to copy, and give the field a name that does not invite `0` as a sentinel. If you also want a `wroteHeader bool` — useful to record only the code the client really received when a handler calls `WriteHeader` more than once — set it in both places: ```go func (r *recorder) WriteHeader(code int) { if !r.wroteHeader && code >= 200 { r.status = code r.wroteHeader = true } r.ResponseWriter.WriteHeader(code) } ``` Two details in that guard matter. **Always forward the call**, whatever the latch decides — the wrapper records, it never censors. And **ignore codes below 200**: `net/http` supports informational 1xx responses (`103 Early Hints`, for example) by calling `WriteHeader` with a 1xx code before the final status, so a latch that grabs the first code it sees would log `103` for a perfectly ordinary `200`. `net/http` also ignores a second *final* `WriteHeader` and writes a superfluous-`WriteHeader` warning to `Server.ErrorLog`, so latching the first final code is what keeps the log matching the wire. ## What the fix does not cover - **The client that hangs up early.** Seeding 200 is an assumption: if the connection dies before anything is flushed, you log 200 for a response nobody received. That is generally accepted, but pair the status with the byte count and the error from `Write` so a truncated response is still visible in the data. - **Handlers that write a body and then try to change the status.** The status is already on the wire; the wrapper cannot fix that and should not pretend to. - **A panic inside the handler.** The recorded status then reflects whatever went out before the panic, not the eventual outcome. ## Proving it This is trivially unit-testable and should be locked down with a test, because the failure is silent and only shows up as a wrong number on someone else's dashboard: ```go rec := httptest.NewRecorder() req := httptest.NewRequest(http.MethodGet, "/", nil) w := newRecorder(rec) http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { fmt.Fprint(w, "ok") })(w, req) // w.status must be 200 even though the handler never called WriteHeader ``` Note that `httptest.NewRecorder` starts its own `Code` field at 200 for exactly the same reason, which is a decent hint that the standard library considers seeding the sane default the right answer rather than a hack. ## The general lesson A wrapper that observes another component has to model that component's **defaults**, not just its explicit calls. Anywhere the observed API has an implicit behaviour — an implicit status, an implicit content type, an implicit close — the zero value of your recording field is a lie waiting to reach a dashboard.