fix(e2e): hard + body-validate the hub /healthz probe (BUNYIP-185) #204

Merged

nrupard merged 1 commit from fix/BUNYIP-185-hub-healthz-hard-probe into main

2026-06-23 19:24:40 +02:00

nrupard commented

2026-06-23 19:19:43 +02:00

Owner

What

Tightens the hub /healthz reachability probe from soft to hard + body-validating, now that staging serves the real endpoint (BUNYIP-185, follow-up to BUNYIP-149).

Why / what changed beyond a plain flip

Verifying the deploy surfaced two things a plain soft->hard flip would miss:

Body validation. bunyip-web has a soft-404 fallback (.fallback(public::not_found)) that returns HTTP 200 + HTML for any unknown path. So a 200 alone never proves /healthz is real - the fallback would satisfy a status-only probe forever. The hub probe now requires the JSON body {"status":"ok"}.
Prod-apex carve-out. psa.systems still serves the fallback (prod deploys on releases, not every merge), and the hub probe runs against prod on a production dispatch. So it's hard + body-validating everywhere except the prod apex, which stays soft until psa.systems serves /healthz. This keeps the merge-gating PR path (staging) strictly enforced without breaking prod dispatches.

The API /health probe is split into its own status-only hard probe() (no soft param, per the issue AC); the hub uses probeHub().

Verified

curl https://a8n.systems/healthz -> 200 application/json {"status":"ok"} (real endpoint).
curl https://psa.systems/healthz -> 200 text/html (still the fallback -> the carve-out).
node --check clean.

Follow-up

Remove the PROD_APEX_HOST carve-out + the soft branch in probeHub once psa.systems serves /healthz (next prod release).

🤖 Generated with Claude Code

## What Tightens the hub `/healthz` reachability probe from soft to **hard + body-validating**, now that staging serves the real endpoint (BUNYIP-185, follow-up to BUNYIP-149). ## Why / what changed beyond a plain flip Verifying the deploy surfaced two things a plain `soft`->`hard` flip would miss: 1. **Body validation.** bunyip-web has a soft-404 fallback (`.fallback(public::not_found)`) that returns **HTTP 200 + HTML** for any unknown path. So a 200 alone never proves `/healthz` is real - the fallback would satisfy a status-only probe forever. The hub probe now requires the JSON body `{"status":"ok"}`. 2. **Prod-apex carve-out.** `psa.systems` still serves the fallback (prod deploys on releases, not every merge), and the hub probe runs against prod on a production dispatch. So it's hard + body-validating **everywhere except the prod apex**, which stays soft until `psa.systems` serves `/healthz`. This keeps the merge-gating PR path (staging) strictly enforced without breaking prod dispatches. The API `/health` probe is split into its own status-only hard `probe()` (no `soft` param, per the issue AC); the hub uses `probeHub()`. ## Verified - `curl https://a8n.systems/healthz` -> `200 application/json {"status":"ok"}` (real endpoint). - `curl https://psa.systems/healthz` -> `200 text/html` (still the fallback -> the carve-out). - `node --check` clean. ## Follow-up Remove the `PROD_APEX_HOST` carve-out + the `soft` branch in `probeHub` once `psa.systems` serves `/healthz` (next prod release). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nrupard added 1 commit

2026-06-23 19:19:43 +02:00

fix(e2e): hard + body-validate the hub /healthz probe (BUNYIP-185)

E2E / Playwright against deployment (pull_request) Successful in 27s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 4m43s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

3d9acc65e3

BUNYIP-149 made the hub /healthz probe SOFT to avoid deadlocking the PR that introduced the endpoint (staging did not serve it yet). Staging now serves the real endpoint (a8n.systems/healthz -> 200 application/json {"status":"ok"}), so tighten it.

Two changes beyond a plain soft->hard flip, both discovered when verifying the deploy:

1. Body validation. bunyip-web has a soft-404 fallback (`.fallback(public::not_found)`) that returns HTTP 200 + HTML for ANY unknown path. So a 200 alone does NOT prove /healthz is the real endpoint - the fallback would satisfy a status-only probe forever. The hub probe now requires the JSON liveness body `{"status":"ok"}`; a 200-HTML fallback fails it.

2. Production-apex carve-out. psa.systems still serves the fallback (prod deploys on releases, not every merge), and the hub probe runs against prod on a production dispatch. So the hub probe is hard + body-validating everywhere EXCEPT the prod apex, which stays soft (warns, continues) until psa.systems serves /healthz. This keeps the merge-gating PR path (staging) strictly enforced without breaking prod dispatches. Remove the PROD_APEX_HOST carve-out + the `soft` branch in probeHub once prod is deployed.

The API /health probe is split into its own status-only hard `probe()` (no `soft` param, per the issue AC); the hub uses `probeHub()`.

node --check clean.

#BUNYIP-185

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>