Display names now survive email-confirmation flows via user_metadata backfill

Davemaina1 fixes a Supabase signup race that silently drops display names for users who go through email confirmation. The pattern - write to user_metadata at signup, merge on the backend at login - is applicable to any product using Supabase auth with a separate profiles table.

intakeinfrastructure

Two failure modes cause the bug. First, when email confirmation is required, there's no active session immediately after supabase.auth.signUp(), so any post-signup write to user_profiles that depends on an access token can fail silently. Second, users who signed up before the name-write path existed have no display_name at all.

The fix touches three files.

In signup/page.tsx, full_name and first_name (extracted as trimmedName.split(/\s+/)[0]) are now passed in the options.data object to supabase.auth.signUp(). This stores them in Supabase user_metadata, which doesn't require a session - it's a property of the auth record itself and survives the confirmation gap.

In AuthContext.tsx, ensureProfile gains a userMeta parameter. Every time a session is established (both the initial auth listener and the subscription callback), session.user.user_metadata is passed through. The function extracts first_name, falling back to the first token of full_name, and includes it as display_name in the POST /user/profile request body.

On the backend (user.ts), the POST /user/profile handler checks for a display_name in the request body. If present and the current user_profiles.display_name is empty, it writes it. If the row already has a display name, no update happens. The guard is explicit: existing?.display_name?.trim() before the update query.

That idempotency matters. The handler is now called on every login. Without the guard it would overwrite later profile edits on each sign-in.

So what Worth applying if your fork has the same Supabase auth + profiles table setup and you're seeing missing display names after email confirmation. The fix is ~80 lines across three files and carries no external dependencies. The `user_metadata`-as-fallback pattern is broadly reusable beyond just display names.

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from Davemaina1/iroh_, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`76bd08c8`	fix: display name persists across logins via user_metadata backfill	Davemaina1	2026-05-14	↗ GitHub
commit body - Store first_name in Supabase user_metadata during signup (works even when email confirmation delays the session) - On every login, ensureProfile sends the auth metadata name to POST /user/profile which backfills display_name if currently empty - This guarantees display_name is set even if the signup PATCH failed Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

SHA

Subject

Author

Date

76bd08c8

fix: display name persists across logins via user_metadata backfill

Davemaina1

2026-05-14

↗ GitHub

commit body

- Store first_name in Supabase user_metadata during signup (works even
  when email confirmation delays the session)
- On every login, ensureProfile sends the auth metadata name to
  POST /user/profile which backfills display_name if currently empty
- This guarantees display_name is set even if the signup PATCH failed

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-383.md from inside the repo you want the changes in.