A Go template rendered <no value> where a name should be. What produced it, and how would you make it an error?

## What actually prints `<no value>` When a template action evaluates to a value that reflection reports as invalid — most commonly a map index whose key is absent, or an untyped nil — the default behaviour of `text/template` is to write the literal text `<no value>` and carry on. It is not an error, not a warning, and nothing in the output distinguishes it from text you meant to print. The important asymmetry is what dot is: - **Dot is a struct.** `{{.FirstName}}` is resolved against a known type. If the field does not exist, or is unexported, `Execute` returns an error like `can't evaluate field FirstName in type mail.Payload`, and nothing further is rendered. Loud. - **Dot is a map.** `{{.FirstName}}` becomes a map index. A missing key is a perfectly legal lookup that yields nothing, and the default option prints `<no value>`. Silent. So the same field rename produces a hard failure or a wrong document depending purely on whether the payload is typed. That is the fact to lead with in an interview, because it also dictates the fix. ## The missingkey option `(*Template).Option` takes option strings and returns the template, so it chains: ```go t, err := template.New("welcome").Option("missingkey=error").Parse(src) ``` The three settings: - `missingkey=default` (alias `missingkey=invalid`) — the default. Continue and print `<no value>`. - `missingkey=zero` — substitute the zero value of the map's element type. An absent string key renders as empty, an absent int as `0`. Quieter than the default and still not an error. - `missingkey=error` — `Execute` stops and returns an error naming the missing key. It applies to **map index operations only**. It does not make struct field misses stricter (they are already errors) and it does not validate anything at parse time. ## Diagnosing the incident Suppose a notification worker sent a batch of emails reading "Hi <no value>, your plan renews on <no value>". The template is fine; the payload changed. A field in the variables map was renamed upstream — `first_name` became `given_name` — and nothing failed. The diagnosis is mechanical once you know the rule: grep the rendered output for `<no value>`, then check whether the actions that produced it index a map. From there: 1. **Make it fail in tests.** Build a table of (template, representative payload) pairs and execute every one with `Option("missingkey=error")`. Any key a template needs and a payload lacks now returns an error, and the test names both sides. This is cheap, runs in milliseconds, and catches the renamed-key class completely for the payloads you enumerated. 2. **Decide the production posture.** `missingkey=error` in production converts a cosmetically wrong message into a failed send. For a notification worker that is usually right — a retry queue plus an alert beats a customer reading `<no value>`. For something where partial output is better than none, `missingkey=zero` at least removes the alarming placeholder. The decision is per system, and it should be a deliberate one rather than the default nobody chose. 3. **Remove the class.** Replace `map[string]any` payloads with a struct per template. Then a renamed field is a compile error in the Go code that builds the payload, or at worst a loud `Execute` error — never a silently wrong document. Maps are convenient exactly where they are dangerous: when the shape is not written down. 4. **Add an output guard.** A rendered-body check for `<no value>` before sending is a crude but effective backstop for the templates you cannot convert yet. ## Related traps in the same family - A nil pointer field prints `<nil>` rather than `<no value>` — different text, different cause, and worth recognising in output. - A key present with an empty value renders as empty, indistinguishable in the output from a key you never referenced. `missingkey=error` does not help there; only a content assertion does. - Chained access `{{.Vars.plan.name}}` where `plan` is missing fails differently depending on the type at each hop; test the whole chain, not the first field. ## What to say in an interview The strongest answer names the mechanism (`<no value>` is the default map-miss behaviour), the asymmetry (structs error, maps do not), the switch (`Option("missingkey=error")` and its three settings), and the systemic fix (typed payloads plus a template-times-payload test), and closes with the judgment call about whether a missing key should stop a send in production.