tegwick
12cd7e0d29
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a10e2d-a5ef-7e92-b03d-b1694e915680
3.5 KiB
Personal login HTTP500 correction — 2026-10-06
The user confirmed receipt of a fresh platform password-reset email, then reported Server Error500 after authentication. End-to-end personal app login is now accepted after the correction below. CSOC-WP-0008-T11 and CSOC-WP-0010-T03 are done.
Diagnosis
The app's identity-linking client requests /api/v1/me on USER_ENGINE_BASE_URL. The deployed historical address https://users.92-205-62-239.nip.io returns302 to https://users.coulomb.social/api/v1/me. httpx does not follow redirects by default; raise_for_status rejects302. establish_session calls that client before recording last_login_at or establishing the Django session; its failure is uncaught by the callback. This explains the reported symptom; raw traceback was not available from the production app's recent stdout log.
Credential-safe in-pod probes send an empty claims envelope (no subject/issuer) using the configured service credential internally: old address302; canonical address400 missing claims. This establishes the canonical address accepts the service credential without creating an identity, sending email, exporting credentials or impersonating the user. It does not prove full signed-in use.
Correction deployed
Owning railiance-apps main commit3f8276e changes USER_ENGINE_BASE_URL in chart defaults and production overrides to https://users.coulomb.social. Helm lint passed. Node-side server dry-run and parsed manifest comparison passed, proving only that environment value changes. Image, Secret references, issuer/client/ tenant, PVC, access rules and every other manifest field remain unchanged.
This completes the personal app deployment already approved by the founder (“Go on and deploy the interruption is not a problem.”), decision 8bbce691-a787-4140-9cd4-df06e8635a27. Authority: ADMINISTER @ realm:kubernetes/railiance01, activation=APPROVED. Node IP verified92.205.62.239. Node-side Helm --reuse-values --atomic --wait --timeout5m succeeded: release coulomb-social revision11 deployed, chart0.2.0, same image digest sha256:bf975939e22b9b0a5d9ac05584ae6265ba201169df6dc48e506ec684b30a9c58. One of one replicas available. Public /healthz and landing200, login302. Post-deploy in-pod empty-claims probe confirms canonical base URL,400 response and no redirect using the existing service credential (probe exit0). Rollback target: Helm revision10, which restores the historical URL.
Acceptance
The user was asked to start a fresh sign-in at https://app.coulomb.social/auth/login/ and report workspace access or error. Only that successful interactive flow closes personal-login acceptance. Inbox receipt is accepted separately. No private protocol was imported and Bubble remains on the apex.
Final acceptance: the user replied “I reach my workspace” after revision11 deployment. This confirms actual interactive personal workspace access; CSOC-WP-0008-T11 / CSOC-WP-0010-T03 complete. ReichelAg migration and paired restore acceptance remain separate open tasks.
Read-only post-acceptance identity check: exactly one Member for the existing issuer/subject, active user, last_login_at within15minutes, platform link present. Verified issuer tenant is tenant:platform rather than app fallback tenant:coulomb; current code uses verified issuer tenant. Before real protocol transfer, CSOC-WP-0008-T03 must reconcile that tenant with target-space ownership and explicit memberships. No cross-tenant grant or automatic data reassignment was made. This does not invalidate personal workspace/login acceptance.