Repository navigation
charts: tls: null aborts the render of nats, qdrant and postgres #4115
Description
Describe the bug
Three app charts read .Values.tls.enabled directly, and tls: null in the values, which their values.schema.json accepts and a HelmRelease override delivers unpruned, aborts the whole render with nil pointer evaluating interface {}.enabled:
helm template x packages/apps/<chart> --namespace tenant-test --set '_cluster.cluster-domain=cozy.local' --set tls=null- nats fails in
templates/_tls.tpl(nats.tls.enabled) - qdrant fails in
templates/_helpers.tpl(qdrant.tls.enabled) - postgres fails in
templates/db.yamlthroughpostgres.tls.enabled
rabbitmq renders, because its helper goes through dig "enabled" nil (.Values.tls | default dict) and then kindIs "invalid". mongodb renders on tls: null but has a separate hole one step earlier: without _cluster it dies on index .Values._cluster "cluster-domain" (#4046). opensearch has the same class on dashboards: null, nodeRoles: null and images: null.
Environment
- Cozystack main, 2026-09-07
To Reproduce
- Run the command above for nats, qdrant or postgres
Expected behaviour
A null the schema admits renders as the default, or is refused with a values error naming the field.
Actual behaviour
The HelmRelease fails and the operator gets a template stack trace.
Additional context
The rabbitmq helper shape is the fix for the three; the opensearch reads and the mongodb _cluster read want the same guard. Found while reviewing #2683 and #2682.
Checklist
- I have checked the documentation
- I have searched for similar issues
- I have included all required information
- I have provided clear steps to reproduce
- I have included relevant logs
Activity
lexfrei commentedon Sep 10, 2026
Same class, three more keys, in a chart this issue does not list. In
packages/apps/opensearch,dashboards: nulldies attemplates/security.yaml:116:16andnodeRoles: nullattemplates/opensearch.yaml:43:34, both on a nil dereference from a key the schema accepts.replicas: nullis the same root with a quieter symptom, and the more dangerous one: the render succeeds and emits an emptyreplicas:into the nodePool and into the WorkloadMonitor,opensearch.yaml:213and:257. Nothing fails, so nothing tells you the count was dropped.Reachability is narrower than the
tlscases: the apps API defaults these keys, so only raw Helm values get there, not an application spec. All three reproduce identically onmaintoday, so the guard belongs with the rest of this rather than in the branch that touched those templates.The remedy is the one this issue already names, and rabbitmq already demonstrates it: read through
(.Values.<key> | default dict)at the leaf rather than guarding the block.lexfrei commentedon Sep 23, 2026
Duplicate of #3705, which covers the TLS helper in nats, qdrant, postgres and kafka. The opensearch keys from the comment above are the only new part, and they fit there.