fix(GPP-burgerportaal): honour 0 for sitemapCacheDurationHours and downloadTimeoutMinutes

[xiduzo]

Wat is er aan de hand

charts/GPP-burgerportaal/templates/configmap.yaml rendert deze twee settings op truthiness:

{{- if .Values.settings.sitemapCacheDurationHours }}
SITEMAP_CACHE_DURATION_HOURS: {{ ... }}
{{- end }}

In Go templates is 0 falsy. Dus juist de waarde die je op een testomgeving wilt zetten — sitemapCacheDurationHours: 0 om de sitemap-outputcache uit te zetten — verdwijnt stilletjes uit de ConfigMap. De app valt dan terug op zijn eigen default van 23 uur.

Hetzelfde geldt voor downloadTimeoutMinutes.

Hoe dit zich uitte

In de e2e-pipeline (kind + deze charts) bouwde de burgerportaal de sitemap één keer, vroeg in de run terwijl de stack nog leeg was, en serveerde die lege XML de rest van de suite uit de cache:

45 x "Serving response from cache."
 1 x "Sending HTTP request"      <- één enkele ODRC-call in de hele run

Gevolg: elk scenario dat een document seedt en daarna in de sitemap opzoekt viel om tegen een sitemap met 0 entries, terwijl ODRC 20-40 documenten als gepubliceerd + isGereedVoorPublicatie rapporteerde. Dat leest als een propagatie- of timingbug in de tests, en dat is het niet.

De fix

Renderen op "is de waarde gezet?" in plaats van op truthiness:

{{- if not (kindIs "invalid" .Values.settings.sitemapCacheDurationHours) }}

Geverifieerd met helm template:

waarde	voor	na
sitemapCacheDurationHours: 0	env var afwezig	SITEMAP_CACHE_DURATION_HOURS: "0"
default (23)	"23"	"23"
expliciet null	afwezig	afwezig

helm lint charts/GPP-burgerportaal is schoon.

Chart version

gpp-burgerportaal gaat naar 2.0.1 — de release-workflow publiceert een chart alleen als de versie wijzigt, dus zonder bump bereikt de fix niemand.

Follow-up (bewust niet in deze PR)

charts/GPP-stack/Chart.yaml pint gpp-burgerportaal: 2.0.0, dus consumers van de umbrella krijgen deze fix nog niet. Ik heb die bump er niet in gelaten: chart-releaser resolvet de dependencies van gpp-stack uit de gepubliceerde index, en 2.0.1 bestaat daar pas nadat deze merge zelf gepubliceerd is — een bump in dezelfde PR kan de release-run dus laten falen. Beter een losse bump nadat 2.0.1 er staat.

🤖 Generated with Claude Code