Why can't an inner handler pass a tenant id back up to an outer middleware through r.Context()?

## The symptom An outer middleware wants to log the tenant each request was resolved to, and the tenant is only known deeper in the chain, where the routing decision has been made: ```go func logging(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { next.ServeHTTP(w, r) id, _ := TenantFrom(r.Context()) // always "" log.Printf("tenant=%q", id) }) } ``` The inner handler demonstrably attached the value — a log line there prints it — and the outer middleware demonstrably runs afterwards. The read still yields nothing. Nothing is broken; the design says this cannot work. ## Why it cannot work **Contexts derive downward.** Attaching a value to a context does not insert anything into that context. It allocates a new context whose parent is the one you passed, holding one key and one value. Lookups walk from child toward root, so a child can see everything its ancestors hold and an ancestor can see nothing its descendants added. The outer middleware holds the parent; the value lives in a child it has no reference to. **Requests are copied, and variables are local.** `r.WithContext(ctx)` returns a new `*http.Request`. When the inner handler writes `r = r.WithContext(ctx)`, it changes what its own parameter variable points at. The outer middleware's `r` is a different variable in a different frame, still pointing at the request it passed to `next.ServeHTTP`. Even if it were the same pointer, the context field would still be the old one, because `WithContext` does not write through the pointer. This is not an accident of the API. It is what makes a middleware chain safe to reason about: whatever a frame passes down, it still holds afterwards, and no code below it can alter the request or context it will use for its own after-work. ## The pattern that does work If an outer frame needs a value produced below it, it must send something *mutable* down before the call, because the downward direction is the only one that works. A pointer to a per-request struct does that: the pointer is copied downward like any value, and both frames end up referring to the same allocation. ```go type tenantHolder struct{ id string } type holderKey struct{} func logging(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { h := &tenantHolder{} // one per request r = r.WithContext(context.WithValue(r.Context(), holderKey{}, h)) next.ServeHTTP(w, r) log.Printf("tenant=%q", h.id) }) } ``` The handler below fills it: ```go if h, ok := r.Context().Value(holderKey{}).(*tenantHolder); ok { h.id = tenant } ``` The outer middleware still holds `h`, so after `next.ServeHTTP` returns it reads what was written. Note that the *context* is still immutable — the value it carries is a pointer, and the pointee is what changed. ## The two mistakes that make this dangerous **Hoisting the holder out of the request.** The tempting simplification is to keep the tenant on the middleware struct itself, or in a package-level variable, since "the middleware only handles one request at a time". It does not. `net/http` runs each request in its own goroutine against the *same* handler value, so every concurrent request writes the same field. The result is not a crash but a mix-up: a response computed for one tenant logged, or scoped, under another. It is also a data race, which the race detector will report on a `-race` build if two requests overlap during the run — and will report nothing at all if they happen not to. The holder must be allocated inside the handler func, per request. **Writing the holder from a goroutine.** If the handler starts a goroutine that fills the holder, the outer middleware's read after `next.ServeHTTP` returns is no longer ordered after that write. Either the write must happen before the handler returns, or the field needs a mutex or an atomic. A plain string field written from another goroutine and read here is a race regardless of whether you observe it. ## Alternatives worth naming Often the better answer is to remove the need. If the outer middleware is the one that wants the tenant, let the outer middleware resolve it and attach it on the way down — then every frame below sees it, and nothing has to travel upward. Reserve the holder pattern for values only the inner layers can know, such as the identifier of the record a handler actually served, and keep the struct small and explicitly documented as request-scoped so nobody is tempted to cache it anywhere longer-lived.