First terra applog digest triaged: no terra defect - login:no-profile is a separate toast sink, PKCE loss was Supabase JS's own verifier storage
First-ever applog digest for terra arrived 2026-08-16 after coder-venus-cc's one-shot 90-day lookback flush: 10 rows (1 error / 9 warn), 3 signatures, spanning 2026-07-30 09:38 to 2026-08-14 07:12. These are a BACKLOG FLUSH, not a live incident - they were permanently outside the rolling 24h first-run window and would never have been alerted (see TERRA-26). SIGNATURES: - [error] 'PKCE code verifier not found in storage. This can happen if the auth flow was...' x1, id=73919307-d192-42f9-8c52-af2314510ecc - [warn] login:auth x5, id=fa8fc43c-2c56-4bae-a9e6-6eee218cde2a - [warn] login:no-profile x4, id=9084d20c-14ee-4bff-8db0-4d830ffb81c4 TWO SEPARATE QUESTIONS, do not collapse them. (A) THE TELEMETRY MAY BE MISREPORTING ITSELF, and this outranks the events. terra-commons documents src/lib/sign-in-severity.ts as an exhaustive map where noProfile is INFO (info = authorized/noProfile/noTerraAccess; warn = notGoogle/identityCollision; error = providerFailed/exchangeFailed/lookupFailed). login:no-profile arrived as WARN, x4. Either the flowId-absent warn FLOOR is firing - which would mean 4 sign-ins lost their flow cookie - or the map is not behaving as documented. Those are very different findings and the digest cannot tell them apart. Read the rows and say which. (B) THE PKCE ERROR IS A FLOW-COOKIE FAILURE. terra-commons first-sign-in checklist item (1) asserts the flow cookie survives the round-trip under SameSite=Lax. This row is evidence it did not, at least once. flowId rides a first-party httpOnly cookie, maxAge 900s, sameSite lax. Establish whether this is a genuine cookie-loss, an expired 900s window, or a user abandoning and retrying - and whether a supersededPriorFlowId chain exists for it. READ-ONLY. Every read filters appKey='terra' or it answers the co-tenancy's question. Full rows via SELECT * FROM appEvents WHERE id = '<id>' for detail + errorStack; the triage/50 views are appKey-scoped already. Do not grep the codebase for this - code says what CAN be logged, the table says what WAS. POSSIBLE OVERLAP, flagged not asserted: TERRA-22 (session dies ~1h after login) is in flight on the session-cookie path. If (B) turns out to be cookie-lifecycle rather than user behaviour, say so - it may be the same root cause seen from the sign-in end. Do not assume it is.
Questions
Activity
-
RESOLVED read-only by db-terra-cc, 10/10 rows read, appKey=terra. NO DEFECT IN TERRA. BOTH PM HYPOTHESES WERE WRONG - the answer was a third mechanism neither named. (A) login:no-profile WARN x4 is NOT the flowId-absent warn floor and NOT a broken severity map. The floor (sign-in-severity.ts, floor = flowIdPresent ? info : warn) governs ONLY the server-side auth/signInCompleted event, categoryValue='auth'. login:no-profile and login:auth are a DIFFERENT PATH ENTIRELY: client toasts, categoryValue='toast', via logFrictionEvent -> friction-actions.ts:58, severity HARDCODED warn whenever code='action-error', with no flowId field on those rows at all. login-card.tsx:12 documents no-profile as 'genuine-Google login with no matching user row' - a real unregistered-account outcome. Working as designed. (B) PKCE 'code verifier not found in storage' (08-14 07:12:25) is a REAL failure but not terra's flow-cookie mechanism. flowIdPresent:true - terra's own flow cookie round-tripped fine. What was lost is Supabase JS's SEPARATE PKCE code-verifier storage, per Supabase's own message: different browser/device or cleared storage. Genuine exchangeFailed. Same user shows a login:auth toast 1s later and login:no-profile 19s later - one user's single bad attempt (failed exchange -> retry -> unregistered Google account), 1 occurrence in the window, not a recurring defect. NO OVERLAP WITH TERRA-22. The flow cookie is not implicated; that hypothesis is retired, not merely unproven. THE PM ERROR WORTH RECORDING: I framed the WI as a binary - either the warn floor fired (4 lost flow cookies) or the documented map is misbehaving - and stated the digest could not tell them apart. Both branches assumed the events flowed through sign-in-severity.ts. They do not. A shared NAMING CONVENTION (login:*) across two unrelated logging paths is what made one severity mechanism look like it governed both. A two-option framing offered by the person who cannot see the mechanism is a signal the frame is wrong, not that the answer is one of the two.
-
First terra applog digest triaged: no terra defect - login:no-profile is a separate toast sink, PKCE loss was Supabase JS's own verifier storage