Orphaned-auth heal: re-link on login + replace stale non-allowed email; triage 27 users with missing auth.users rows

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2026-06-05
• wi-cli-venus spec · 2026-06-05
  SCOPE (db+coder investigation 2026-06-05, surfaced via dead #235): COHORT (db): 122/443 non-demo users have BROKEN auth (cannot log in) = 28%. Split: 6 supabaseAuthId NULL (never bound) + 116 orphaned FK (authId set, auth.users row deleted). NOT domain-correlated: 71 gmail, 24 uba, only 27 non-standard. So #235's 'non-allowlist domain' filter was wrong predicate; authoritative criterion = missing auth.users row. Engagement: 105/122 have studentAssignments (enrolled), 0/122 have ANY practicas, 17 fully dormant. HEAL MECHANICS (coder, callback/route.ts + auth.ts): re-link by EMAIL EQUALITY. Orphaned user logs in via Google -> new auth id -> lookupUserBySupabaseAuthId=null -> lookupUserByNormalizedEmail (callback:164, email-only match) -> updateUserSupabaseAuth rebinds authId same row (callback:199) -> HEALED, history preserved, no domain gate, no bounce. REQUIRES Google email == stored email (normalized). Sub-cases: (a) orphaned authId NON-null => previously did Google OAuth on that email => self-heal by re-login with EXACTLY that email, no admin. (b) never-bound / email not a Google account => OAuth fails => admin must switch stored email to a working Gmail FIRST then user logs in -> match -> heal. NEVER 'use any Gmail' without admin step (different gmail = no match = bounced to /solicitar-acceso = orphan/dup trap). ELAZAR DESIRED BEHAVIOR: heal on login should delete old not-allowed email + replace with the one they logged in with. NOTE: current code re-links by email-EQUALITY so cannot auto-replace a DIFFERENT email; would need a different match key — open design Q if built. STATUS: deprioritized by Elazar (cohort presumed dormant ex-students, 0 practicas supports). Parked low-pri. If built: new action+template ('restaura tu acceso', per-user 'entra con Google usando EXACTAMENTE <su email>'), NOT sendNonWhitelistMigrationEmails. a19fa33 audit-before-send fix already shipped+kept.
• wi-cli-venus spec · 2026-06-05
  TARGETING SPLIT (coder, for eventual heal campaign) — 122 broken-auth, all have >=1 role (no /acceso-denegado risk on re-link): - Type A, 116 orphaned-FK (self-healable by re-login with stored email): 65 gmail (definitely Google accounts, cleanest), 24 odontologia.uba.ar (UBA institutional, Google-OAuth unconfirmed), 27 non-allowlist (20 hotmail + 7 icloud/yahoo/outlook — previously did Google OAuth so email was a Google account once). - Type B, 6 never-bound (all gmail): Google-capable addresses, never logged in, self-heal too. EXECUTION: ~71 are dead-simple 'entra con Google con tu email' (gmail + never-bound). The 24 UBA + 27 non-allowlist need the 'use EXACTLY that email; if not a Google account, admin switches it first' caveat.
• wi-cli-venus completed · 2026-06-05
  Closed no-action per Elazar 2026-06-05. Investigation conclusion: the 122 broken-auth users are NOT blocked — zero login attempts across all 122 (db: no failed-auth events). Root cause = March 2026 Supabase project migration (public.users restored from old project, supabaseAuthId points at old project's auth rows). Any user self-heals on first re-login via callback email-fallback rebind (callback:164→199); 293 users from the same cutover already did so silently. No code bug, no wall, no admin heal required. Decision: if they want to log in they'll ask. Heal-mechanics + cohort detail preserved in this WI's event log for future reference.