A Helm chart fails to render with `nil pointer evaluating interface {}.tag` — how do you find the cause?

### The anatomy of a Helm render error When a chart fails to render, Helm surfaces the underlying Go template error more or less verbatim, and its structure is worth reading carefully because it names every part of the problem. A typical one: ``` Error: template: operator-chart/templates/indexer-job.yaml:23:38: executing "operator-chart/templates/indexer-job.yaml" at <.Values.indexer.image.tag>: nil pointer evaluating interface {}.tag ``` Four pieces: - **`operator-chart/templates/indexer-job.yaml`** — the template being executed. This is a path inside the *chart*, not a path in the rendered output. - **`23:38`** — line 23, column 38 **of that template file**. This is the single most misread part of the message: people open the rendered YAML and count lines. There is no rendered YAML for that file — rendering is what failed. - **`at <.Values.indexer.image.tag>`** — the exact expression being evaluated when it blew up. This tells you which value to go and look at. - **`nil pointer evaluating interface {}.tag`** — the failure kind. It means the *parent* was nil: `.Values.indexer.image` did not exist, so asking it for `.tag` had nothing to look up. It does **not** mean `tag` was set to an empty string; an empty string renders fine (usually into a broken but syntactically valid manifest). ### Following the chain into a helper When the failure happens inside a named template, the message nests. You get the caller's file and line, an `error calling include` clause, and then a second `template: ...:LINE:COL: executing "<name>"` for the helper, typically in `templates/_helpers.tpl`. Read it from the right: the rightmost frame is where evaluation actually failed, and the frames to its left tell you who invoked it and with what. That matters because the fix is often not in the helper at all — the helper is fine, and the caller handed it something that lacked a field. ### The reproduction loop The first move is to get the failure onto your own machine with no cluster in the way: 1. Re-render locally with the *exact* values the failing run used: `helm template <name> <chart> -f <the same file> --set <the same overrides>`. Templates are a pure function of values plus release metadata, so if you have the same inputs you get the same failure. 2. Narrow with `-s/--show-only templates/indexer-job.yaml` so you are looking at one file's render and not scrolling past everything else. 3. Add `--debug` for verbose output — Helm is much more forthcoming about what it was doing, and you get whatever it managed to produce rather than a bare one-line error. 4. Confirm the diagnosis by supplying the missing key on the command line. If `--set indexer.image.tag=x` makes the render succeed, the template is not the bug; the values are. Expect to iterate. Helm reports the failure it hit, and fixing that one can reveal the next. ### Reading it as a values problem, not a chart problem Consider an operator chart that has been upgraded thirty-four times without incident and now fails to render its document-indexing Job. Two things can have changed: the chart (someone edited a template or bumped the chart version) and the values (someone changed a `-f` file, added a `--set`, or removed a key). The error's `at <...>` clause decides between them for you. If it names a `.Values` path, the chart asked for something that was not supplied — go and diff the values inputs. If it names a function call or a helper, look at the template change. A third possibility deserves naming because it is easy to miss: a key can disappear because a values file *replaced* a structure rather than merging into it, or because a value the chart expected to be a map arrived as a string. The template does not care why the key is gone; the error is the same nil pointer either way. ### Distinguishing render errors from everything else Not every failure that mentions YAML is a render error. A **template execution error** always names a template file with a line and column and an `at <...>` expression, and it produces no manifest for that file. A failure that appears *after* the render — a complaint about parsing or converting the produced document, or a rejection from the API server naming a field — happened downstream of a successful render, and you chase it by looking at the rendered text or the object, not at the template's line numbers. Sorting the message into the right bucket in the first ten seconds is most of the debugging. ### Guardrails worth having Charts that hand a caller a clear message when a required value is absent fail far more legibly than charts that dereference three levels deep and die on a nil. Rendering the chart against each of its shipped values files in CI catches the whole class before anyone runs an upgrade.