feat(extension-server): branded data-plane error pages#205
Merged
Conversation
Serve a Datum-branded HTML error page for edge-generated 5xx responses on the downstream / Connector data plane, replacing raw bodies like "no healthy upstream" that visitors see during a customer outage. The extension server attaches an Envoy local_reply_config to every RDS-based (customer-facing) HCM during PostTranslateModify, mirroring the existing Coraza listener mutation: - New mutator InjectLocalReplyConfig (mutate/localreply.go): one response mapper, status_code_filter >= minStatusCode gated by a runtime key, body + content-type override, original status code preserved. Skips non-RDS HCMs (EG readiness listener), idempotent, no-op when disabled or body empty. - Embedded default page (assets/error-5xx-default.html) compiled into the operator as an always-valid fallback. - GatewayConfig.errorPage block (enabled / bodyPath / minStatusCode, plus defaulted runtimeKey + contentType); run.go sources the body from the optional ConfigMap mount and falls back to the embed on any read problem. - Optional envoy-error-pages ConfigMap volume mounted read-only at /etc/datum/error-pages; pod starts cleanly when the ConfigMap is absent. - New nso_extension_local_reply_mutations_total metric + log/trace fields. Fail-safe by construction: with failOpen:false on the downstream EG, a hook error blocks xDS fleet-wide, so the injector only errors on a genuinely malformed HCM. Missing/empty content is a no-op, never an error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
scotwells
marked this pull request as ready for review
June 19, 2026 13:45
Contributor
|
@scotwells do you want to merge this and then i can re-create the old template in a new pr? |
Contributor
Author
|
@mattdjenkinson we'd keep the real template we use in the infra repo so we don't need to do software releases to update the template |
Contributor
|
Sorry apparently i completely ignored that in the enhancement doc! |
mattdjenkinson
approved these changes
Jun 19, 2026
This was referenced Jun 19, 2026
fix(extension-server): deterministic tunnel-offline 503 on the user path for offline connectors
#207
Merged
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
When a customer's site is reached through Datum's edge and the origin can't be served — an offline Connector tunnel, a down backend, a timeout — Envoy answers, not the customer's app. On the downstream/Connector data plane that's a raw
503 no healthy upstream. This serves a Datum-branded HTML error page there instead — the page a customer's own users see during the customer's outage.Implements the Branded Data-Plane Error Pages enhancement — proposal in #204 (doc).
What changed
InjectLocalReplyConfiglistener mutation in the extension server: any edge-generated response ≥ 500 renders the branded body (status code preserved). Covers HTTP/2 and HTTP/3 listeners; skips internal/readiness listeners; idempotent.envoy-error-pages) with a compiled-in fallback — works out of the box, editable later via GitOps.gateway.errorPage.{enabled,bodyPath,minStatusCode}.Notes for review
failOpen:false; missing/empty content is a no-op, and the injector errors only on a malformed HCM.envoy-error-pagesConfigMap content + a content-change reload are a follow-up in the infra repo.golangci-lintskipped locally (go1.25 vs repo's go1.26.4 toolchain — not a code issue).Draft — not for merge/release yet; pending live verification on staging (503 → branded HTML).
🤖 Generated with Claude Code