In Go's log/slog, how do the variadic key/value arguments work, and what is !BADKEY?
answer
- arguments arrive two at a time
- a string key, then its value
- or a ready-made slog.Attr instead
- one leftover argument still needs a key
- vet notices the odd count
basics
~20 slog/slog reads its variadic arguments as alternating pairs: a string key followed by its value, or a ready-made slog.Attr such as slog.String("pkg", p). A key left with no value is logged under the placeholder key !BADKEY.
solid answer
~50 sEvery log/slog logging call takes a message plus a variadic list of `any`, and slog turns that list into attributes. It reads a string as a key and takes the next argument as that key's value; if it instead finds a `slog.Attr` built by a constructor like `slog.String`, `slog.Int` or `slog.Any`, it uses that attribute directly, so both styles can be mixed in one call. The typed constructors make the value's type visible at the call site and can be stored and passed around, for example into `slog.Group`. When the argument list ends with a dangling key, slog neither panics nor drops it: it records an attribute whose key is the literal string `!BADKEY` and whose value is the orphan argument, so the mistake shows up in the log line instead of breaking the program. `go vet` has a slog analyzer that reports such mismatched calls statically.
code
go · 8 lineslogger := slog.New(slog.NewTextHandler(os.Stdout, nil))
// a key/value pair and a typed Attr in the same call
logger.Info("generated", "pkg", "store", slog.Int("decls", 12))
// the trailing key has no value to pair with
logger.Info("generated", "pkg", "store", "count")
// the record carries pkg=store and !BADKEY=countgo deeper
Be ready to write a slog call from memory: a constant message, then key/value pairs, and know that slog.String and slog.Int build the same attribute in typed form.
Explain how slog walks the argument list, when it consumes one argument versus two, and exactly what a reader should conclude when !BADKEY shows up in a line.
Show how you keep malformed calls out of production: go vet's slog analyzer wired into CI, and a review habit of preferring typed attribute constructors where the value's type is not obvious.
Own the convention across teams: whether services standardise on typed attribute constructors or loose pairs, and how that is enforced by tooling rather than relitigated in every pull request.
## The two argument forms The logging methods in `log/slog` — `Logger.Info`, `Logger.Warn`, `Logger.Error`, `Logger.Debug` and `Logger.Log` — take a message string followed by `args ...any`. That loose signature is deliberate: it lets one call carry either cheap key/value pairs or fully typed attributes, and lets a codebase migrate from one to the other without changing the call shape. slog walks the `args` slice from the front and, at each step, looks at the next value: - If it is a **string**, slog treats it as a key and consumes the *following* argument as that key's value. Two arguments are used. - If it is a **`slog.Attr`**, slog uses it as-is. One argument is used. - Anything else in a key position cannot be a key, so slog records it under `!BADKEY` and consumes only that one argument. A `slog.Attr` is a tiny struct: a `Key string` and a `Value slog.Value`. The constructors `slog.String`, `slog.Int`, `slog.Int64`, `slog.Uint64`, `slog.Float64`, `slog.Bool`, `slog.Time`, `slog.Duration` and the catch-all `slog.Any` each return one. Because an `Attr` is an ordinary value, you can build it once, keep it in a variable, pass it to another function, or hand it to `slog.Group` as part of a nested set. ## What !BADKEY actually is `!BADKEY` is a literal string constant inside `log/slog`, used as the key for an argument slog could not interpret. Two situations produce it. The first is the dangling key. `logger.Info("generated", "pkg", "store", "count")` has an odd number of arguments after the message. The pair `"pkg", "store"` is consumed normally; then `"count"` is a string with nothing after it, so slog emits an attribute keyed `!BADKEY` whose value is the string `count`. Text output shows `!BADKEY=count`; JSON output shows `"!BADKEY":"count"`. The second is a non-string in a key position. `logger.Info("generated", 12, "pkg", "store")` starts with `12`, which cannot be a key, so slog records `!BADKEY=12` and consumes only that one argument. Everything after it has now shifted by one, so `"pkg"` becomes a *value* and `"store"` becomes a *key* — the whole tail of the record comes out mis-keyed. That cascade is why the mistake is worth catching statically rather than eyeballing the output. The design choice behind `!BADKEY` is that logging must not be able to take down the program it is observing. A malformed call produces a malformed line, not a panic and not a compile error, because the signature is `...any` and the compiler has nothing to check. ## Catching it before it ships `go vet` includes a slog analyzer that understands these call shapes. It reports calls where the key/value arguments do not pair up and calls where a key is not a string constant it can prove is a string, at build time and with no runtime cost. Running `go vet ./...` in CI turns a class of silently broken log lines into a failed check, which is the whole point: the code that emits a log line is usually the code nobody exercises in a test. For the engineer arriving from a language where logging means formatting, the mental shift is that there is no format string here. `logger.Info("generated %s", pkg)` compiles and runs, and produces the message `generated %s` with no attributes at all — a perfectly valid record that says nothing useful. The message is a constant human-readable string; everything variable belongs in attributes, where a downstream consumer can index and query it. ## Practical guidance Use plain key/value pairs where the call is short and the values are obviously typed. Reach for the typed constructors when the value's type is not obvious from the expression, when you want the compiler to check it, or when you need the attribute as a value — building a group, or collecting attributes in a slice before logging. Keep key names consistent across a service, because the consumer queries on those strings, and remember that keys are just strings: nothing stops two layers from choosing the same one.
- What happens if a non-string value turns up where slog expects a key?slog cannot use it as a key, so it records that single argument under !BADKEY and moves on. Because one argument was consumed instead of two, every later pair shifts by one and the rest of the record comes out mis-keyed. That cascade is why go vet's slog analyzer treats a non-string key as an error rather than a style nit.
- Why offer slog.String and slog.Int when a bare key and value already work?They build a slog.Attr, which is an ordinary value you can name, pass to another function, or hand to slog.Group when nesting. They also put the value's type in the source, so a reviewer sees what is being logged. A loose pair is interpreted only at run time, and a mistake in its shape surfaces as !BADKEY in a log line rather than as a compile error.
- Can a badly formed slog call ever stop the program?No. slog is deliberately forgiving at run time: a dangling or non-string key becomes an !BADKEY attribute and the record is still written, so the damage is a malformed log line rather than an outage. Nothing panics and nothing is silently discarded. The check you want is static, and that is go vet reporting the mismatched call.
The argument list is read like a shopping list of label-then-item. Hand over a label with no item behind it and slog does not throw the list away — it files the stray label in a drawer marked !BADKEY so you can see what went wrong.
saying these in an interview costs you the question
- Thinks log/slog takes a printf-style format string
- Says a dangling key is silently dropped
- Claims an odd argument count fails to compile
- Believes a mismatched slog call panics at run time
- Assumes only slog.Any can carry a value