How do you write a slog.Handler that adds a run id from the context to every record?

## The shape of the problem A migration tool walks a table in batches. Every line it emits over the next two hours belongs to one run, and a support engineer chasing one customer's run through a day of output needs a `run_id` on all of them. Threading a `runID string` parameter into every function that might log is invasive and gets forgotten. The standard answer in `log/slog` is to put the identity in the `context.Context` once and have the *handler* stamp it. ## The Handler interface ```go type Handler interface { Enabled(context.Context, Level) bool Handle(context.Context, Record) error WithAttrs(attrs []Attr) Handler WithGroup(name string) Handler } ``` Two of those methods receive a context, and `Handle` is the one that matters here: it is called with the context the caller passed to `InfoContext`, `ErrorContext` or `Logger.Log`, and it is handed the `slog.Record` about to be written. ## The wrapper The idiom is a decorator over a real handler: ```go type runKey struct{} type runHandler struct{ inner slog.Handler } func (h runHandler) Handle(ctx context.Context, r slog.Record) error { if id, ok := ctx.Value(runKey{}).(string); ok { r.AddAttrs(slog.String("run_id", id)) } return h.inner.Handle(ctx, r) } ``` Points worth stating in an interview: - **The comma-ok assertion is not optional.** Plenty of log lines will be emitted from contexts that never carried a run id — startup, shutdown, tests. A bare `.(string)` assertion panics on those. - **`Record.AddAttrs` appends to the record you were given.** If your handler fans the same record out to more than one destination, take `r = r.Clone()` first so the copies do not share attribute storage. - **Forward, do not swallow.** `Handle` must call the inner handler; it is the thing that actually formats and writes. ## The three methods people forget `Enabled` is a straight delegation: `return h.inner.Enabled(ctx, l)`. `WithAttrs` and `WithGroup` are the trap. It is tempting to embed `slog.Handler` in the struct and let the promoted methods handle those two — but the promoted `WithAttrs` returns the *inner* handler, so any logger derived from yours drops the wrapper and quietly stops stamping run ids. Implement both to re-wrap: ```go func (h runHandler) WithAttrs(as []slog.Attr) slog.Handler { return runHandler{h.inner.WithAttrs(as)} } ``` This is the single most common defect in hand-rolled context handlers, and it fails silently: the lines still appear, the field is just missing on some of them. ## Installing it and feeding it ```go h := runHandler{inner: slog.NewJSONHandler(os.Stdout, nil)} slog.SetDefault(slog.New(h)) ``` `slog.New` builds a `*slog.Logger` over the handler; `slog.SetDefault` makes the package-level `slog.InfoContext` shorthand use it too, which matters in a codebase where not every component is handed a logger. The other half is the context. At the top of the run you derive one context that carries the id and pass it down: ```go ctx = context.WithValue(ctx, runKey{}, id) ``` From then on the obligation on call sites is exactly one thing: use the Context-taking log methods. `logger.Info("...")` gets `context.Background()` and comes out unstamped no matter how good your handler is. ## What belongs in the context, and what does not Keep the context value small and identity-shaped: a run id, a batch number, a customer id, a request id. It is data other things want too — an error message, a metric label, the id you print to the operator at the end. Do not push whole subsystems through it. ## Testing it The handler is easy to test without a running service: build one over `slog.NewJSONHandler` writing into a `bytes.Buffer`, log once with a context carrying an id and once with `context.Background()`, and assert the field is present in the first line and absent from the second. Add a case that derives a logger through `WithAttrs` and logs again — that is the case that catches the dropped-wrapper bug, and it is the one people leave out.