docs: record post-redeploy auth diagnosis

This commit is contained in:
2026-08-16 19:57:10 +08:00
parent 0324afee04
commit 763d2f0648

View File

@@ -0,0 +1,60 @@
# Task: Diagnose production login failure after redeploy
## Identity
- Task ID: 20260816-prod-login-still-failing-7e3c91a4
- Mode: Feature
- Branch: main
- Worktree: D:\Datas\OthersProjects\NianAIGC
- Base commit: 0324afee04ea4ea4543dd7b4063418cc3caf4c2d
- Owner: codex
- Status: Ready for Integration
## Scope
- Diagnose why authenticated production `/create` still fails after the user redeployed the `498c2fa` repair.
- Build a deterministic browser feedback loop, distinguish rollout/configuration failures from an application-contract defect, and keep live evidence redacted.
- If the root cause is repository-owned, add the narrow regression coverage and minimal fix without restoring database credentials to Next.js.
## Intent And Constraints
- Preserve ADR-003 while diagnosing the deployed repair; the user subsequently superseded its SSR requirement by explicitly choosing a pure static frontend with all APIs owned by Go.
- Do not inspect or print session Cookie values, passwords, Secret values, or database connection details.
- Treat the user's statement that production was redeployed as current evidence; the integrated canonical statement that `498c2fa` is not deployed may now be stale and requires later Integration Gate reconciliation.
- Separate confirmed browser/HTTP evidence from cluster-level hypotheses because this machine currently has no Kubernetes context.
## Outcome
- Reproduced the post-redeploy failure twice in the signed-in in-app Browser: `/create` consistently renders the Next.js production Server Component error with Digest `3316070080`.
- Confirmed the post-redeploy Digest differs from the pre-redeploy Digest `1739392469`, so a changed production build or failure path is live; this does not by itself prove every ConfigMap or Pod environment change took effect.
- Confirmed anonymous public `GET /api/auth/me` and `/api/ready` return HTTP 200 with the expected anonymous auth shape and PostgreSQL configured, respectively.
- Static review found no normal-path JSON contract mismatch between the current Next parser and Go handler/resolver. The checked-in Service name, port, selectors, ConfigMap reference, and shared Secret reference are internally consistent.
- A local production replay with a valid signed platform session and a blank `ZHINIAN_GO_INTERNAL_BASE_URL` reproduced the same symptom class: authenticated `/create` returned HTTP 500/RSC error and the server logged `ZHINIAN_DATA_BACKEND must be explicitly set to 'local' or 'postgres'`.
- The leading live hypothesis is therefore a stale/missing Web Pod environment after the ConfigMap change. ConfigMap values are read only at Pod start, and the checked-in deployment has no ConfigMap checksum trigger. Web-to-Go reachability and Go resolver infrastructure failure remain the next hypotheses.
- Root cause remains unconfirmed because the current machine has no configured Kubernetes context for Web Pod environment, endpoints, or logs.
- The user confirmed the desired resolution is architectural rather than another SSR bridge patch: production frontend becomes static output, browser requests same-origin Go APIs directly, and the Next server-side authentication path is removed. A separate migration task owns that implementation.
## Verification
- Browser reload feedback loop: signed-in `https://nianxxaigc.nianxx.cn/create` reproduced Digest `3316070080` on both observations.
- `curl.exe -sS -i --max-time 15 https://nianxxaigc.nianxx.cn/api/auth/me` — HTTP 200 with the expected anonymous response shape.
- `curl.exe -sS -i --max-time 15 https://nianxxaigc.nianxx.cn/api/ready` — HTTP 200 and PostgreSQL configured.
- `kubectl config current-context` — no current context is set.
- Local replay: a production build with a test-only signed session, blank internal Go URL, and no Next data backend returned HTTP 500; local Next logs contained the deterministic direct-store configuration error.
- `go test ./internal/httpapi ./internal/identity ./internal/application` — passed in the read-only contract review.
- `npm run deploy:check` — passed all 9 static ACK manifest checks; this check does not inspect live Pod environment, image IDs, Service endpoints, or rollout state.
## Follow-ups
- From an authenticated production-cluster context, inspect only whether the running Web Pod has `ZHINIAN_GO_INTERNAL_BASE_URL`, compare the live Web image ID with the intended release, probe Web-to-Go `/api/health` and anonymous `/api/auth/me`, inspect the Go Service EndpointSlice, and correlate Digest `3316070080` with the Web container log.
- If the ConfigMap is correct but the Pod environment is blank, roll the Web Deployment after applying the ConfigMap; do not print Secret values.
- Superseded for the target architecture: the new static-frontend migration should remove the Web-to-Go SSR bridge instead of further hardening this deployment path.
## Promotion Candidates
- Target: deployment verification guidance and the authenticated SSR regression contract.
Proposal: replace the production SSR/Web-to-Go bridge with a static frontend whose browser-facing auth Module calls same-origin Go `/api/auth/me`; update ADR-003 and deployment verification accordingly.
Evidence: the static ACK checker passes, while the local blank-URL replay produces the same fatal authenticated RSC symptom class and the live cluster remains red after a reported redeploy.
Future impact: removes the production Node/SSR workload and its internal auth transport, leaving Go as the sole backend authority and Nginx/Ingress as the static host and same-origin router.
Semantic conflicts: supersedes ADR-003 statements that Next.js remains an SSR server and calls Go over internal HTTP.
Human confirmation required: received explicitly from the user on 2026-08-16.