With slog's HandlerOptions.AddSource enabled, why does every record's source point at one helper file?

## What AddSource actually does `slog.HandlerOptions` has three fields, and `AddSource bool` is the one that makes a handler emit a `source` attribute — a `*slog.Source` carrying `Function`, `File` and `Line` — under the built-in key `source`. In JSON output that is a nested object; in text output it is rendered inline. The part worth internalising is *where the information comes from*. A `slog.Record` has a `PC` field: a `uintptr` program counter. The `Logger` methods capture it when the record is created, using `runtime.Callers` with a fixed skip count chosen so that the frame recorded is the code that called `Logger.Info`. `AddSource` does not capture anything — it only decides whether the handler spends the work of translating that PC into a file, line and function name at write time. That split matters twice: it explains the cost (the frame lookup is the expensive part, and it is paid in the handler, per record, only when the option is on), and it explains the bug. ## The bug: a wrapper eats the frame Teams wrap `slog` constantly, and for reasonable motives — to bind a request id, to enforce a house message format, to make the logger swappable in tests, or simply because the codebase already had `logInfo(msg, args...)` before `slog` existed and the migration kept the signature. ```go func logInfo(msg string, args ...any) { slog.Info(msg, args...) // this line is the caller slog records } ``` The skip count inside `slog` counts frames from `Logger.Info`. It has no way to know that the frame it lands on is a shim rather than real code. So the PC on every record points at that one line in that one file, and with `AddSource` on, every record in the service reports the same `source`. This is a nastier failure than having no source at all: an on-call engineer filters to an error, reads a precise `file:line`, opens it, and finds the logging helper. The information is not missing; it is confidently wrong. The same trap catches a wrapper one level up too — a `type Logger struct{ *slog.Logger }` with a method that calls the embedded logger's method — and it catches an ad-hoc `defer` or `errors`-handling helper that logs on the way out. ## Fixing it The standard fix is to stop using the `Logger` convenience methods inside the wrapper and construct the record yourself, so you control the skip count: ```go func (l *Wrapper) Info(ctx context.Context, msg string, args ...any) { if !l.h.Enabled(ctx, slog.LevelInfo) { return } var pcs [1]uintptr runtime.Callers(2, pcs[:]) // skip runtime.Callers and this method r := slog.NewRecord(time.Now(), slog.LevelInfo, msg, pcs[0]) r.Add(args...) _ = l.h.Handle(ctx, r) } ``` Four things are going on here: 1. **`runtime.Callers(skip, pc)`** fills `pc` with program counters. `skip = 0` is `runtime.Callers` itself, `1` is the function that called it — this method — and `2` is that method's caller, which is the code we actually want to blame. 2. **`slog.NewRecord(t, level, msg, pc)`** builds the record with that PC instead of one slog captures for us. 3. **`Record.Add(args...)`** takes the same alternating key/value form the `Logger` methods accept; `Record.AddAttrs` takes typed `slog.Attr` values instead. 4. **`Handler().Handle(ctx, r)`** bypasses the `Logger` entirely — which is the point, and also why the `Enabled` check has to be done explicitly first. Handing a record straight to a handler skips the check the `Logger` would have performed, so without that guard you do the record-building work even when nothing will consume it. The alternative fix is to have no wrapper: let call sites use `*slog.Logger` directly and get bound context via `Logger.With`, which returns a real logger rather than a shim. That removes the problem instead of compensating for it, and it is usually the better answer when the wrapper exists only to attach a couple of attributes. ## Is AddSource worth having on? It is a per-handler boolean, so it is on for every record or none. The value is highest when messages repeat across files (`"failed"`, `"retrying"`) and lowest when every message string is already unique enough to grep for. The cost is a frame resolution per emitted record plus three more fields on the wire. Measure it on your own hot path before deciding — and if you turn it on, verify on a real record that the file it names is a call site and not your logging package, because that check takes ten seconds and the failure mode above is silent. ## Interview framing Say where the PC comes from, that `AddSource` only resolves it, and that a fixed skip count plus a wrapper equals a permanently wrong answer. Then name the fix concretely: `runtime.Callers`, `slog.NewRecord`, `Handler().Handle`.