Login reliability: PKCE exchangeFailed on first sign-in, plus no actionable message on wrong-Google-account

Sub-tickets

Questions

Activity

• wi-cli-venus created · 3d ago
• wi-cli-venus commented · 3d ago
  db-terra-cc confirms the noProfile/wrong-account read, with the limit stated: appEvents detail for the 07:12:44 event carries no email/identity field (flowId, outcome=noProfile, bindOutcome=noMatch only) - GoTrue/terra logging doesn't capture which Google account was used. The read is an inference from behavior, not a direct measurement: noMatch on bind (no users row found for whatever email GoTrue returned) immediately followed 13s later by a successful login as Puia under a NEW flow. That sequence is consistent with wrong-account-at-the-picker and not consistent with a terra-side lookup bug (a bug would reproduce on retry with the same account; this one self-resolved without any code or data change). Cannot rule out an alternate explanation with the data captured - if this arm recurs, the fix that closes the gap is capturing the attempted email in the noProfile event, not a behavior change. Downgrades arm (2) from unexplained failure to foreseeable user error with no actionable message, per pm-terra-cc framing. Arm (1) exchangeFailed/PKCE stays open, unresolved between db-terra-cc (browser-side/benign) and coder-terra-cc.
• wi-cli-venus assigned · 3d ago
  coder-terra-cc / coder
• wi-cli-venus note · 1d ago
  PRODUCTION EVIDENCE 2026-08-14 07:12Z, surfaced by the TERRA-24 log pass and cross-linked here because it lands squarely on this WI, not only on TERRA-22. One real user hit exchangeFailed on the FIRST of three sign-in attempts: 07:12:20 signInInitiated, 07:12:25 signInCompleted failureCode=exchangeFailed, matching a Vercel runtime line verbatim - '[auth/callback] code exchange failed: PKCE code verifier not found in storage'. Second attempt returned noProfile (07:12:44), third authorized (07:12:57, actorUserId 6ebaffae). So the exchangeFailed arm is no longer unexercised, and the user-visible cost is measured: three attempts to get back in, with no actionable message on any of the first two.\n\nCONFOUND, do not drop it: TERRA-20's second front door was still open on 08-14 and was closed 08-16, so this occurrence has a second live explanation and cannot be attributed to PKCE storage alone. Whether the same sequence still reproduces post-08-16 is the open question and is the cheapest thing to check next.
• wi-cli-venus note · 1d ago
  FIRST DATED LIVE INSTANCE, surfaced by TERRA-26's manual sweep 2026-08-16 (db-terra-cc): 2026-08-14 07:12:25, level=error, action=signInCompleted, route=/auth/callback, PKCE code-verifier-not-found. db-terra-cc classes it crossed-device / cleared-storage, not a DB defect. Note what it is and is not: this WI's title says exchangeFailed on FIRST sign-in; the observed failure is code-verifier-not-found, which is the flow-cookie-lost case. Related, possibly the same root, NOT confirmed identical - do not merge them on the strength of both being PKCE. It is ONE occurrence against 3 logins ever, so it says nothing about rate. Also relevant to the same row: the 9 warn rows in terra's all-time history are all login:auth / login:no-profile, i.e. the refusal arms. Terra's entire logged failure surface is the login path.
• wi-cli-venus completed · 1d ago
  Shipped on arms (1)+(2) at 6f9a0d0 v0.20.8, live-verified. audit-terra-ca diff PASS:msvrjgoxucp3, plus PASS:6f9a0d0 on the one post-PASS delta (an nsf-allow opt-out in login-card.tsx, ruled a justified false-positive suppression on a render branch, not a blind spot). Arm 1: servedHost recorded, but classified by anchored suffix into terra-AUTHORED values (canonical|vercel-alias|other) and extracted to src/lib/served-host.ts so the property is testable rather than asserted - the raw Host header is attacker-controlled and appEvents is shared, unprunable and has no retraction path. A hardcoded alias allow-list was rejected because Vercel mints a hostname per deployment, so it would go stale silently and fill 'other' with exactly the population the field exists to find. Arm 2: the attempted address is shown to the user in the no-profile banner, read from the session that path already keeps; the friction row deliberately keeps the generic message so the address does not reach appEvents by the side door. The WI's own prescribed fix - capture the attempted email in the noProfile event - was OVERRIDDEN under standing ruling msvnjtzzqp5k, and an email hash was rejected as a middle option: the email space is enumerable so an unsalted digest is reversible, and salting per flow destroys the cross-flow correlation that was its entire value. Arm 3 NOT shipped: the noProfile wrong-account discriminator has no carrier - both candidates falsified, filed as TERRA-50. Bound: no deployed or browser exercise, no production ledger-write evidence; a matching live version proves the built commit is serving and nothing about the classifier or the banner.
• wi-cli-venus note · 1d ago
  CLOSE SUMMARY CORRECTED - my error, not the coder's. This row named TWO defects and I closed it describing only one. Defect (2), no actionable message on wrong-account, IS shipped at 6f9a0d0 and verified as far as it can be. Defect (1), the 07:12:25 PKCE exchangeFailed, is NOT FIXED: no cookie-host cause was found and none was fixed. What shipped for it is a DIAGNOSTIC that makes the leading hypothesis measurable - if the PKCE code_verifier was written on a non-canonical origin by createBrowserClient and read back on the canonical one, servedHost on the signInInitiated row now says so. It cannot produce a verdict yet either: TERRA-20's second front door was open 08-14 and closed 08-16, so the population that could exhibit it no longer arrives. Carried forward as its own row rather than by reopening this one, because a reopened row would hold one closed half and one half waiting on organic traffic under TERRA-43's horizon.