From 19e9fd2328c12ac7db703fc7a23079526aadb0e2 Mon Sep 17 00:00:00 2001 From: Macky Date: Tue, 18 Aug 2026 14:41:00 +0700 Subject: [PATCH] docs: record JWT_SECRET boot-crash root cause for 2026-08-18 deploy --- docs/engineering-log/2026-08-18-live-qa-ux-fixes.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/engineering-log/2026-08-18-live-qa-ux-fixes.md b/docs/engineering-log/2026-08-18-live-qa-ux-fixes.md index f4f0769..2e807c8 100644 --- a/docs/engineering-log/2026-08-18-live-qa-ux-fixes.md +++ b/docs/engineering-log/2026-08-18-live-qa-ux-fixes.md @@ -82,3 +82,14 @@ within ~10+ min. The exact reported leak payload was re-run through the NEW pars reply (no leak), so the code fix is correct — the leak seen was the stale deploy. Action: force a redeploy (re-push to re-trigger the webhook, or redeploy from the EasyPanel console) and re-verify the live bundle contains the new auto-close guide text. + +### Root cause of non-boot (same day) + +The re-triggered deploy DID build, but the new container **crash-loops on boot**: +`RuntimeError: JWT_SECRET must be configured with at least 32 characters` in +`Config.validate_runtime_security()` (`backend/app/config.py:111`, production default, workers exit +code 3). The old live image ran pre-strict-check code, so it never enforced this. The UX fix commits +sit on top of the strict security code (S4.x), which fails closed in production without a valid +`JWT_SECRET`. Fix is **env config, not code**: set `JWT_SECRET` (≥32 chars, random) in the EasyPanel +service environment, then Redeploy. `BOOTSTRAP_ADMIN_PASSWORD` (≥12) is only required for first-run +admin init; log shows users already exist (`require_bootstrap=False`), so JWT_SECRET alone unblocks boot.