Three AKS config keys are set in values and rendered by no template — SelfUpdate__MinRollInterval, WebhookInbox__Targets__0, AzureFoundry__Models__3 #1925

Three config keys are set in deploy/aks/values.aks.yaml and rendered by nothing

Found while fixing the same defect for Modules__Root (#1924). Filing rather than patching, because templating each of these changes live AKS behaviour, and two are recent, deliberate work by their authors.

The mechanism

deploy/helm/templates/memex-portal/memex-portal/config.yaml names every ConfigMap key explicitly, there is no catch-all range over config.memex_portal, and the Deployment's only env path is envFrom on that ConfigMap plus the Secret. A values key the template omits reaches no container, with no error anywhere. helm is happy: the values file is syntactically perfect and the template simply never mentions it.

The three

AzureFoundry__Models__3 is the clearest tell: its three siblings are templated and it is not, so this reads as an addition that missed the template rather than a deliberate omission.

SelfUpdate__MinRollInterval is the one worth reading twice. AGENTS.md documents it as the fix for restart churn — "#1780 closed that with SelfUpdate__MinRollInterval, a restart budget set to 1h in values.aks.yaml beside the 24h/6h/1h trade" — and warns that its predecessor key SelfUpdate__PollInterval "sat in the chart inert, reading as a live daily throttle, until #1778." That is this defect, one key earlier, already fixed once.

How to confirm

grep -rn "SelfUpdate__MinRollInterval\|WebhookInbox__Targets__0\|AzureFoundry__Models__3" deploy/helm/templates/
# → no matches

kubectl -n <ns> get configmap memex-portal-config -o json | jq '.data | keys[]' | grep -E "SelfUpdate|WebhookInbox|Models__3"
# → nothing, on any AKS namespace

Why it is not in #1924

Each would take effect on merge-and-deploy: the self-update restart floor would start applying, and webhook routing would change. Those are decisions for whoever set them, not a drive-by in a chart fix.

Suggested fix

Template all three (each one line, same shape as their neighbours), then widen the existing guard so this class cannot recur. The guard already exists and already has the right shape — PlatformBakeLaneGuard asserts that a values key is BOUND in the ConfigMap, with a comment explaining that a looser "the key appears somewhere" check would be satisfied by the Helm comment prose. It is simply scoped to keys starting with PreWarm__:

.Where(l => !l.StartsWith('#') && l.StartsWith("PreWarm__", StringComparison.Ordinal))

Widening it to every config.memex_portal key catches exactly these three and nothing else. Two notes for whoever does it:

• Parse the YAML, do not scan lines. A line scan sweeps in the secrets: section, whose keys are legitimately bound in secrets.yaml under .Values.secrets.memex_portal.* — 19 false positives.
• Accept the intermediate-variable pattern. Portal__BaseUrl is emitted via {{- $portalBaseUrl := … }} so it can fall back to the ingress host. Requiring the literal <key>: "{{ .Values.config.memex_portal.<key> binding flags it wrongly; requiring emitted as a ConfigMap key and .Values.config.memex_portal.<key> referenced somewhere in the template handles both shapes.

With those two adjustments the widened guard reports exactly the three above.