appEvents context columns exist and terra writes none of them (sessionId, userAgent, ip, requestId, traceId)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 1d ago
• wi-cli-venus note · 1d ago
  LIVE EVIDENCE from TERRA-26's manual sweep 2026-08-16: of terra's 10 all-time error/warn rows, the 9 warns carry NO route and NO errorMessage. The single error row does carry route=/auth/callback. So the under-attribution this WI describes is not hypothetical - it is 90% of terra's logged failure history, and the rows least attributed are the warns, which are exactly the ones needing context to be actionable. Concretely: 9 rows say a login refusal happened and cannot say where or to whom. That is the cost of the missing context columns, measured rather than argued.
• wi-cli-venus note · 1d ago
  CORRECTING THE 2026-08-16 08:34 NOTE ON THIS WI, which is wrong in a way that would misdirect the design. I read all 10 error/warn rows back from appEvents at appKey=terra. The 9 warns are NOT under-attributed login refusals. They are CLIENT-SIDE FRICTION rows: categoryValue=toast, written by emitFriction from useActionForm, actions login:auth (5) and login:no-profile (4). They carry no route and no errorMessage BY DESIGN - both are server-side concepts and this rail has neither. What they DO carry is detail.code, detail.field, detail.mechanism=inline-hint, the exact Spanish string shown to the user, and a clientEventId uuid. So "9 rows say a login refusal happened and cannot say where or to whom" is not what the rows show: they say precisely WHAT was shown and through which mechanism, which is the half of the story that rail exists to record. The single error row is signInCompleted / exchangeFailed with route=/auth/callback and the full PKCE "code verifier not found in storage" message. WHAT IS ACTUALLY MISSING, and it is a better target than ip or userAgent: the two rails already pair by timestamp and NOTHING JOINS THEM. 09:39:08 warn login:auth sits beside 09:39:08 providerFailed. 10:02:38 warn login:no-profile beside 10:02:37 noProfile. 07:12:26 beside 07:12:25 exchangeFailed. 07:12:45 beside 07:12:44 noProfile. Four clean pairs correlated by nothing but a second-boundary coincidence - exactly the join that silently mismatches the moment two users overlap. clientEventId exists on the client row and has no counterpart on the server row. So the highest-payoff column here is a CORRELATOR, not personal data. Restating this WI's own weighting with the measurement behind it: ip and userAgent are personal data on a shared table with a >=365d retention floor that terra cannot prune, and neither would have made any of these 10 rows more actionable. The design ping to audit-terra-ca will propose on that basis. Not deciding it in a note.
• wi-cli-venus note · 1d ago
  REVISED ACCEPTANCE, granted by pm-terra-cc (msvnjtzzqp5k) after audit-terra-ca SUPPORT-WITH-CHANGES. The original criterion - "columns chosen with the reason, written by the logger, and a query showing them populated" - is RETIRED, not waived: it demanded columns the investigation refuted. THE FIVE NAMED COLUMNS ARE REJECTED. ip/userAgent: appEvents is a SHARED table on a co-tenanted ref with a >=365d retention floor terra cannot prune, so personal data written there is written for enamel too and terra has no retraction path. pm made that half a STANDING ruling binding every future "add context columns to appEvents" ask, to be carried into terra-commons in the same push as the code. sessionId: null-by-construction on this population - a FAILED login has no session, and failed logins are all 10 rows that motivated the WI. requestId/traceId: no producer exists in terra, and adding a producer is a different change from filling a column. WHAT THE 10 ROWS ACTUALLY SHOW is a correlator gap, and the correlator already exists and is already deployed on the server rail: flowId, minted at src/lib/auth-actions.ts:38, carried in the httpOnly terraSignInFlow cookie, written to the completion row at src/app/auth/callback/route.ts:183. It is destroyed one hop before the second rail fires - finish() deletes the cookie at route.ts:200 on EVERY outcome including the failure redirects, and the client friction row is emitted from LoginCard's useEffect after that redirect has landed. The two rails are uncorrelated because the failure path deletes the correlator early, not because terra lacks one. NEW ACCEPTANCE: a login-scoped friction row carries detail.flowId matching its server signInCompleted row, delivered by a dedicated one-use httpOnly failure-bridge cookie consumed server-side in logFrictionEvent. No new columns, no DDL - and therefore nothing enamel reads changes shape, which discharges this WI's enamel constraint rather than satisfying it. THE CORRELATION BOUND, recorded in the WI because a future reader finds this and does not find the test file: THE JOIN IS A STRONG ASSOCIATION, NOT PROVEN CAUSATION, BECAUSE A RELOAD OR A HAND-DRIVEN LANDING ON THE SAME ERROR CODE CAN STILL JOIN. Anyone querying on detail.flowId inherits that bound. BINDING CONSTRAINTS on the implementation, from audit and pm: - Dedicated bridge cookie, NOT an extension of the primary flow cookie's life. The primary cookie's completion/deletion semantics are preserved on all paths. httpOnly, secure, lax, path=/, short maxAge. - The bridge carries BOTH the flowId and the expected login error code. logFrictionEvent consumes it only after input validation and only when actionName EQUALS a member of a closed allowed set - not startsWith. Deleted in the same server-action response before the friction write, so it is one-use even if logging fails or retries. - Short maxAge is a SECOND bound behind the same-response deletion (pm): one-use enforced only by a deletion path is a persistent correlator on a shared browser the moment that path fails. - actionName is CLIENT-SUPPLIED and cannot authenticate a flow. The protected cookie supplies the flow id; the equality check is semantic narrowing, not authorization. - FAIL-OPEN (pm): bridge cookie absent - blocked, expired, reload, hand-driven landing - and the friction row IS STILL WRITTEN, without flowId. A missing correlator must never suppress the record; suppressing turns a correlation improvement into a coverage regression, and the regression is invisible because the rows that vanish are exactly the ones nobody could correlate anyway. - A NULL flowId THEN HAS TWO CAUSES - bridge absent vs never minted - and a reader cannot separate them from a null. Carry a discriminator, or this ships the same defect one layer in: never-captured and never-emitted producing identical output. FAILURE COVERAGE, verified against source rather than relayed: providerFailed/exchangeFailed/lookupFailed land on /login?error=auth; notGoogle on /login?error=not-google; noProfile on /login?error=no-profile. identityCollision (/identidad-en-revision) and noTerraAccess (/sin-acceso) never reach LoginCard and are correctly excluded, as are successful sign-ins and bare callback hits. NAMED RESIDUAL: notGoogle has produced ZERO rows ever (callback/route.ts:128), so its arm of this correlator will ship unexercised. TIER: CLASS-A pre-push diff review - it mints a new httpOnly cookie on the auth path. Pre-impl design ping is SATISFIED by audit's SUPPORT-WITH-CHANGES; the diff review is still owed.
• wi-cli-venus completed · 1d ago
  Shipped 9210797, v0.19.0. One-use httpOnly bridge cookie carries flowId from the OAuth callback to the LoginCard friction write; detail.flowIdSource = bridge/bridge-absent/omitted. Five requested columns rejected; ip/userAgent standing ruling shipped in terra-commons in the same push. audit-terra-ca PASS msvompfxdlpa. Limit on the PASS: source/unit/build evidence only - no real browser OAuth->callback->server-action cookie lifecycle and no concurrent-consumption evidence.