feat(web): add /healthz liveness endpoint for e2e + monitoring (BUNYIP-149) #202

Merged

nrupard merged 1 commit from feat/BUNYIP-149-web-healthz into main

2026-06-23 18:40:27 +02:00

nrupard commented

2026-06-23 18:34:00 +02:00

Owner

What

Adds an unauthenticated GET /healthz liveness endpoint to bunyip-web (the SSR hub) and references it from the e2e reachability gate (BUNYIP-149, BUNYIP-148 sub-task).

Why

The e2e suite's reachability gate only probed bunyip-api's /health - it could confirm the OP/API host was up, but not the hub the browser specs actually drive. bunyip-web had no health endpoint for a web-targeted gate or uptime probe.

How

Endpoint (bunyip-web/src/handlers/health.rs): GET /healthz -> 200 {"status":"ok"}, application/json. No auth (registered as a public route; the handler never calls the auth guard), no DB - liveness, not readiness. Mirrors bunyip-api's /health.
Gate (e2e/scripts/health-check.mjs): now probes the API /health and the hub /healthz before the suite runs. The hub probe is soft - it warns on a non-2xx but stays fatal on an unreachable host. PR SHAs never deploy, so on this very PR the live staging hub does not serve /healthz yet; a hard 404 would deadlock the PR introducing it (same deploy-transition shape as BUNYIP-183). Tighten to a hard check once /healthz is deployed everywhere.

AC

GET /healthz returns 200 + minimal body, no auth.
No hard DB dependency (liveness).
Referenced from the e2e reachability gate.

Verification

clippy -p bunyip-web --all-targets -D warnings + fmt --all --check clean; node --check on the gate script clean. No schema change.

🤖 Generated with Claude Code

## What Adds an unauthenticated `GET /healthz` liveness endpoint to bunyip-web (the SSR hub) and references it from the e2e reachability gate (BUNYIP-149, BUNYIP-148 sub-task). ## Why The e2e suite's reachability gate only probed bunyip-api's `/health` - it could confirm the OP/API host was up, but not the **hub** the browser specs actually drive. bunyip-web had no health endpoint for a web-targeted gate or uptime probe. ## How - **Endpoint** (`bunyip-web/src/handlers/health.rs`): `GET /healthz` -> `200 {"status":"ok"}`, `application/json`. No auth (registered as a public route; the handler never calls the auth guard), no DB - liveness, not readiness. Mirrors bunyip-api's `/health`. - **Gate** (`e2e/scripts/health-check.mjs`): now probes the API `/health` **and** the hub `/healthz` before the suite runs. The hub probe is **soft** - it warns on a non-2xx but stays fatal on an unreachable host. PR SHAs never deploy, so on this very PR the live staging hub does not serve `/healthz` yet; a hard 404 would deadlock the PR introducing it (same deploy-transition shape as BUNYIP-183). Tighten to a hard check once `/healthz` is deployed everywhere. ## AC - [x] `GET /healthz` returns 200 + minimal body, no auth. - [x] No hard DB dependency (liveness). - [x] Referenced from the e2e reachability gate. ## Verification `clippy -p bunyip-web --all-targets -D warnings` + `fmt --all --check` clean; `node --check` on the gate script clean. No schema change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nrupard added 1 commit

2026-06-23 18:34:00 +02:00

feat(web): add /healthz liveness endpoint + wire it into the e2e gate

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

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 5m23s

Details

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

Details

2432d8efbd

bunyip-web (the SSR hub) had no health endpoint, so the BUNYIP-148 e2e suite could only confirm the OP/API host was up (bunyip-api /health), never the hub the browser specs actually drive. Add GET /healthz: unauthenticated, no DB, returns 200 `{"status":"ok"}` (liveness, not readiness - mirrors bunyip-api). Registered as a public route before the marketing/auth routes; the handler never calls the auth guard.

Wire it into the PR-mode reachability gate (scripts/health-check.mjs): it now probes the API /health AND the hub /healthz before the suite runs. The hub probe is SOFT (warns on a non-2xx, still fatal on an unreachable host): PR SHAs never deploy, so on this very PR the live staging hub does not serve /healthz yet, and a hard 404 would deadlock the PR that introduces it (same deploy-transition shape as BUNYIP-183). Tighten to a hard check once /healthz is deployed everywhere.

clippy -p bunyip-web --all-targets -D warnings + fmt --check clean; node --check on the gate script clean.

#BUNYIP-149

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