terra
TERRA-210
Galvan Padilla DB bindings completed; post-bind login and access-request behavior remain unexercised
Done high
dtdb02-terra-ca
DB-side status corrected 2026-09-10. The two designated existing profiles are bound to their matching Supabase auth users; each current profile email matches its bound auth email. Live read-only verification found no duplicate-target-profile or cross-binding collision. The original claim that both are unbound and cannot log in is stale.\n\nBoundary: this establishes the profile/auth mapping only. Neither person completing a post-bind login nor the access-request/report path has been exercised after the repair. PostgREST/API availability is an application/platform concern, not evidence that the DB binding failed.\n\nBWI update: retain only the unexercised user-path follow-up; do not request another DB identity repair without new, reconciled evidence.
Activity
-
db02-terra-ca
-
Ambas cuentas Galvan Padilla vinculadas en vivo (marker terra210-bind-mtv8x). Maria Victoria users 4d608021 -> auth 651d03a3, email en ficha galvanvictoria97@outlook.com REEMPLAZADO por panorexis26@gmail.com. Laura Cecilia users 45f57303 -> auth 1ee14e90, email en ficha lauragalvan91@hotmail.com REEMPLAZADO por lauragalvan293@gmail.com. bindSupabaseAuthId devolvio outcome='bound' en las dos; vUsersAccountState isBound=true en las dos; appEvents supabaseAuthIdBound/success 08:06:41Z y 08:06:48Z. GO relevado por coder02-terra-ca (Elazar). Evidencia: agents/db-terra/evidence/2026-09-10-terra_210-galvan-bindings.result.md. NO verificado: ninguna de las dos completo un inicio de sesion despues del vinculo, y PostgREST seguia 503 PGRST002 en /rpc.
-
BLOCK 2026-09-10: live preflight found both designated profiles already bound to their respective auth accounts; each current profile email equals its auth email, but neither equals the stale target email recorded in this WI. No duplicate target-profile or cross-binding collision found. No write performed. PM asked to reconcile stale identity inputs before any further repair.
-
Galvan Padilla DB bindings completed; post-bind login and access-request behavior remain unexercised
-
was: Two real people cannot log in RIGHT NOW. Both have live users rows; both are UNBOUND because the row carries an address they do not sign in with. Same shape as Tomas Cardozo (resolved 2026-09-08), which makes this the second and third instance of the dominant terra failure mode, not an outlier. MEASURED read-only by coder-terra-cc 2026-09-10 against eprpywqwzsvrjeaforei: users 4d608021-dd73-43ca-b22d-b77eb23fc3e4 Maria Victoria Galvan Padilla email galvanvictoria97@outlook.com supabaseAuthId NULL users 45f57303-4f32-4446-b7cd-f4afd4163ada Laura Cecilia Galvan Padilla email lauragalvan91@hotmail.com supabaseAuthId NULL auth.users 651d03a3-4234-4a47-a109-1cfcf8f17119 panorexis26@gmail.com last_sign_in_at 2026-09-09 22:27:08Z auth.users 1ee14e90-6012-40e8-a7b0-f05f4ee1c492 lauragalvan293@gmail.com last_sign_in_at 2026-09-09 22:30:31Z FIX, per person, DB LANE ONLY (the reporter is read-only and did not run these): 1. UPDATE users SET email = <gmail address> WHERE id = <users id> emailCanonical is a GENERATED column - updating it directly raises 428C9. Update email only. 2. SELECT bindSupabaseAuthId(<gmail address>, <auth id>, 'terra') That function is the ONLY sanctioned writer of users.supabaseAuthId. Never write the column by hand. It writes its own supabaseAuthIdBound event. Check for a duplicate profile under any other address before editing either row (see the absence-claim rule): noMatch means "no users row whose email canonicalises to this one", never "this person has no account". WHY IT IS URGENT AND NOT MERELY OPEN. Laura signed in at 22:30:31Z, got the no-profile screen, pressed the report button SEVEN times between 22:31:05 and 22:32:26, received "Ocurrio un error inesperado" every time, and stopped. The button failed because PostgREST has been 503 PGRST002 project-wide for ~31h (empty API > Exposed schemas, dashboard-only, Elazar's). So the escape hatch built in 0.31.44/0.31.48 is itself down: accessIssueReports holds ZERO rows ever. These two have no working way to ask for help, and nobody would learn about them if Elazar had not forwarded the WhatsApp by hand. Evidence forwarded by nw-whey-cc: /data-venus/coder-terra/incoming/2026-09-10-whatsapp-forward/ (2 screenshots, 1 voice note; delete after pickup). Related: TERRA-111 (non-Google addresses, policy), TERRA-6 (identity verification), TERRA-59 (the report path that would have surfaced this).
-
DB identity repair verified live; user-path exercise remains unverified.
-
DB scope complete: live verification confirms both designated profiles are bound to their matching auth users, with matching current emails and no duplicate/cross-binding collision. Post-bind login and access-request behavior remain unexercised application/platform follow-up, not a reason to reopen DB identity repair.
bug
5w ago by wi-cli-venus
5w ago
2026-09-10 15:05