Skip to content

PPT-2536: liveness-probe DB short-circuit + login-form reload on failure#6

Open
camreeves wants to merge 2 commits into
masterfrom
PPT-2536-minor-probe-loginform
Open

PPT-2536: liveness-probe DB short-circuit + login-form reload on failure#6
camreeves wants to merge 2 commits into
masterfrom
PPT-2536-minor-probe-loginform

Conversation

@camreeves

Copy link
Copy Markdown
Contributor

The two remaining minor drop-in items (both auth.cr-only, verified against the Ruby source).

  1. Liveness probe hit the DB before its health short-circuitAuthority.find_by_domain raises when Postgres is unreachable, so a blip 500'd /auth/authority?health and risked a k8s pod-restart storm. Short-circuit moved ahead of the DB call → empty 200, no DB touch. (Correct liveness semantics; noted divergence from Ruby's readiness-ish behaviour.)
  2. Browser login-form failure returned 401 JSON instead of reloading the page — routed the password-failure branches through a login_failure helper that reloads the referrer when a continue is present (browser form) and keeps 401 for API/XHR callers. user-not-found / soft-deleted stay 401 (Ruby parity: head :unauthorized before authenticate).

Specs: ?health returns empty 200 even for a matching host (no DB lookup); wrong password + continue → 303 to referrer; unknown email + continue → still 401. Full suite validated in CI.

🤖 Generated with Claude Code

camreeves and others added 2 commits July 19, 2026 17:36
/auth/authority?health hit current_authority (Authority.find_by_domain)
BEFORE the health short-circuit. That query RAISES (not returns nil) when
Postgres is unreachable, so a transient DB blip 500'd the probe and risked
a pod-restart storm. Move the short-circuit ahead of the DB call: a ?health
caller now always gets an empty process-is-up 200 without touching the DB.
(Divergence from Ruby, which let ?health fail on DB-down / returned the
authority JSON — but that's exactly what you want for a LIVENESS probe.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A wrong/absent password on the browser login FORM returned a raw 401 JSON
body instead of reloading the page. Mirror Ruby SessionsController: route
the password-failure branches through login_failure, which reloads the
referring page when a continue param is present (browser form) and keeps
the 401 for API/XHR callers (no continue). user-not-found and soft-deleted
stay 401 in all cases, exactly as Ruby (head :unauthorized before the
authenticate call).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant