From e61e6a83b55f56f89d885cbae24f7b649229055f Mon Sep 17 00:00:00 2001 From: chrisfu Date: Tue, 21 Apr 2026 15:45:33 -0700 Subject: [PATCH] =?UTF-8?q?fix(supabase):=20kong=20/healthz=20service=20UR?= =?UTF-8?q?L=20=E2=80=94=20drop=20self-reference?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Follow-up to 23f3f14. With the checksum annotation in place, `helm upgrade` did start rolling Kong forward, but the new pod never became Ready: `rollout status` timed out with "1 old replicas are pending termination" Kong's ConfigMap contains the /healthz route correctly, the BackendConfig is HTTP /healthz, but the Kong process itself refuses to start cleanly when one of its services has `url: http://127.0.0.1:8000/` -- Kong's own proxy port. This self-reference apparently trips the declarative-config parser (undocumented; symptomatic only). Switch to a RFC-2606 `.invalid` placeholder. The request-termination plugin short-circuits before any DNS lookup or upstream connection, so a non-resolvable URL is functionally equivalent and Kong's parser has nothing to complain about. Same change in both places we define the /healthz route: - supabase/helm/knoe-supabase/templates/kong/config.yaml (supabase-kong) - etc/init_kong.sh inline kong.yml heredoc (knoe-svc-kong) The knoe-svc-kong backend was already HEALTHY with the self-referential URL -- different Kong instance, possibly different parser path -- but keeping the two configs aligned so future edits don't drift. Co-Authored-By: Claude Opus 4.7 (1M context) --- etc/init_kong.sh | 8 +++++++- .../helm/knoe-supabase/templates/kong/config.yaml | 11 ++++++++++- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/etc/init_kong.sh b/etc/init_kong.sh index cae4e3b..51ef481 100755 --- a/etc/init_kong.sh +++ b/etc/init_kong.sh @@ -382,8 +382,14 @@ services: # returns 200 synchronously with no upstream call, so the probe passes as long # as the Kong proxy itself is running. GCE rejects \`type: TCP\` in BackendConfig # (only HTTP/HTTPS/HTTP2 accepted), so we use this route for HTTP liveness. + # + # URL is a RFC-2606 reserved \`.invalid\` hostname that never resolves. A + # self-referential URL like \`http://127.0.0.1:\${KONG_PROXY_PORT}/\` crashlooped + # the supabase-kong pod on startup (Kong's declarative-config parser appears + # to reject the self-reference). Since request-termination short-circuits + # before any DNS lookup, a non-resolvable placeholder is equivalent. - name: healthz - url: http://127.0.0.1:${KONG_PROXY_PORT}/ + url: http://knoe.healthz.invalid/ routes: - name: healthz paths: diff --git a/supabase/helm/knoe-supabase/templates/kong/config.yaml b/supabase/helm/knoe-supabase/templates/kong/config.yaml index d5dbcc4..7445f5b 100644 --- a/supabase/helm/knoe-supabase/templates/kong/config.yaml +++ b/supabase/helm/knoe-supabase/templates/kong/config.yaml @@ -55,8 +55,17 @@ data: # originally wanted, but using the HTTP protocol that GCE's L7 # BackendConfig CRD actually accepts (TCP is rejected with # `Protocol "TCP" is not valid, must be one of [HTTP,HTTPS,HTTP2]`). + # + # URL is a RFC-2606 reserved `.invalid` hostname that never resolves. + # We originally tried `http://127.0.0.1:8000/` here, which is Kong's + # own proxy port -- this crashlooped the pod on startup (rollout timed + # out waiting for new pod to become Ready). Suspected cause: Kong's + # declarative-config parser rejects the self-reference. Since the + # request-termination plugin short-circuits before any DNS lookup or + # upstream connection, using a non-resolvable placeholder URL is + # equivalent in behavior but avoids the loop detection. - name: healthz - url: http://127.0.0.1:8000/ + url: http://knoe.healthz.invalid/ routes: - name: healthz strip_path: true