mirror of
https://github.com/zitadel/zitadel.git
synced 2026-07-25 18:28:00 +00:00
Mridang AgarwallaandGitHub
db8f475a02
# Which Problems Are Solved The login v2 container has no way to verify upstream Zitadel API connectivity before accepting traffic. The existing `/healthy` endpoint always returns 200 regardless of whether the backend is reachable. This means Kubernetes routes user traffic to pods that cannot actually serve login requests, causing silent failures where the root layout swallows gRPC errors and renders pages with default settings. # How the Problems Are Solved A new `/ui/v2/login/ready` endpoint creates a gRPC client using the same auth and transport path as real requests, calls `SettingsService.getGeneralSettings()`, and returns `200 OK` on success or `503 Service unavailable` on failure. This verifies both network connectivity and authentication credentials to the upstream Zitadel API. Kubernetes supports readiness probes natively, so this endpoint can be configured as a readiness probe to gate traffic until the login container can connect to Zitadel. Docker Compose does not have a readiness probe concept, so the compose healthcheck and `healthcheck.mjs` default remain unchanged and continue using `/healthy`. The Docker HEALTHCHECK in the Dockerfile has been updated to use `/ready` so that the image-level health status reflects actual upstream connectivity. This will also allow us to simplify the Helm chart by dropping the `wait4x` init containers that currently poll the Zitadel API before starting the login pod, since the readiness probe makes them redundant. # Additional Changes The `/ready` endpoint has been added to the OTEL HTTP instrumentation ignore list to avoid noisy probe traces. Unit tests, a wiring spec integration test, and an OTEL span filtering test have been added for the new endpoint. The `# TODO: Check healthy, not ready` comment has been removed from the Dockerfile. The `/healthy` endpoint is kept as-is for liveness probes. # Additional Context The Helm chart changes to use `/ready` for readiness and startup probes and to remove the `wait-for-zitadel` init container will be done in a follow-up PR in the `zitadel-charts` repository.