Le healthcheck du conteneur NestJS était défaillant de deux manières, causant des erreurs HTTP 502 intermittentes depuis nginx-strangler vers le backend NestJS en CI (Merge Queue et tests E2E). Cela se manifestait par des échecs flaky des tests Playwright, notamment service-chains.spec.ts.
1. Mauvais chemin de healthcheck dans le Dockerfile
apps/server-nestjs/Dockerfile utilisait :
HEALTHCHECK ... http://localhost:3001/api/v1/system/healthz
Ce endpoint retourne 404. Le bon chemin est /api/v1/healthz.
2. Healthcheck trop strict — vérifie des services externes non configurés
Le healthcheck Terminus dans healthz.controller.ts vérifiait inconditionnellement tous les services externes (gitlab, vault, nexus, registry, argocd). Quand leurs URLs ne sont pas configurées (comme en CI), ils retournent status: "down", ce qui fait que le healthcheck global retourne 503.
3. Condition de course dans docker-compose
docker-compose.ci.yml, dev.yml et integ.yml utilisaient tous condition: service_started pour la dépendance server-nestjs dans nginx-strangler. Cela signifie que nginx-strangler pouvait commencer à proxifier des requêtes avant que NestJS soit prêt.
Le healthcheck du conteneur NestJS était défaillant de deux manières, causant des erreurs HTTP 502 intermittentes depuis nginx-strangler vers le backend NestJS en CI (Merge Queue et tests E2E). Cela se manifestait par des échecs flaky des tests Playwright, notamment
service-chains.spec.ts.1. Mauvais chemin de healthcheck dans le Dockerfile
apps/server-nestjs/Dockerfileutilisait :Ce endpoint retourne 404. Le bon chemin est
/api/v1/healthz.2. Healthcheck trop strict — vérifie des services externes non configurés
Le healthcheck Terminus dans
healthz.controller.tsvérifiait inconditionnellement tous les services externes (gitlab, vault, nexus, registry, argocd). Quand leurs URLs ne sont pas configurées (comme en CI), ils retournentstatus: "down", ce qui fait que le healthcheck global retourne 503.3. Condition de course dans docker-compose
docker-compose.ci.yml,dev.ymletinteg.ymlutilisaient touscondition: service_startedpour la dépendanceserver-nestjsdansnginx-strangler. Cela signifie que nginx-strangler pouvait commencer à proxifier des requêtes avant que NestJS soit prêt.