Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

A Supabase branch database returns {"code":"unexpected_failure","message":"Database error querying schema"} on all POST /auth/v1/token?grant_type=password requests. The error persists after restarting the project from the Supabase Dashboard. The identical schema and data on the main branch of the same project authenticates successfully.

To Reproduce

1. Create a Supabase branch from a project that has existing auth users (auth.users, auth.identities populated).
2. Apply the public schema to the branch via direct psql connection (not supabase db push) — e.g. using pg_dump --schema-only output piped through psql.
3. Import auth.users rows from main into the branch via INSERT statements (CSV export from Supabase Dashboard → manual INSERT).
4. Create corresponding auth.identities rows for each user:

   INSERT INTO auth.identities (id, user_id, provider_id, provider, identity_data, last_sign_in_at, created_at, updated_at)
   SELECT gen_random_uuid(), id, email, 'email',
     jsonb_build_object('sub', id::text, 'email', email, 'email_verified', true, 'phone_verified', false),
     last_sign_in_at, created_at, updated_at
   FROM auth.users WHERE email IS NOT NULL;
   

POST https://.supabase.co/auth/v1/token?grant_type=password
{ "email": "user@example.com", "password": "validpassword" }

5. Receive HTTP 500: {"code":"unexpected_failure","message":"Database error querying schema"}
6. Restart the project from Dashboard → Settings → Infrastructure → Restart project.
7. Error persists after restart.

Expected behavior
Authentication should succeed with valid credentials. The branch's GoTrue instance should be able to query the auth schema just as the main branch does. Both branches have identical auth schema migrations (verified via SELECT version FROM auth.schema_migrations ORDER BY version DESC), identical tables, identical functions, and identical supabase_auth_admin grants.

Verification steps performed
Confirmed auth.schema_migrations versions are identical on main and branch (latest: 20260302000000)
Confirmed auth.users has 67 rows with valid bcrypt encrypted_password hashes ($2a$10$...)
Confirmed auth.identities has 67 rows with provider = 'email' and correct identity_data
Confirmed email_confirmed_at is set on 66/67 users
Confirmed supabase_auth_admin has USAGE on auth schema: SELECT has_schema_privilege('supabase_auth_admin', 'auth', 'USAGE') → t
Confirmed supabase_auth_admin has SELECT on auth.users and auth.identities: both → t
Confirmed no custom triggers on auth.users
Confirmed all auth schema routines are identical between main and branch
Confirmed all auth schema tables are identical between main and branch
Main branch authenticates successfully with same credentials and password hashes

System information
OS: Windows 11
Browser: Chrome
Version of supabase-js: 2.x (via @supabase/supabase-js)
Version of Node.js: 22.x
Supabase branch ref: rktzrvqrjvjlwmerwbck
Parent project ref: pndyltkvxlhropudcuqw
Region: ap-southeast-2 (Sydney)

Additional context
The branch was populated by:

1. Applying 90 migration files via psql -f directly (bypassing supabase db push due to duplicate timestamp version collision in local migration files)
2. Applying additional DDL for 41 cloud-only tables not present in local migrations
3. Importing auth.users rows via direct INSERT (Dashboard CSV export)
4. Manually creating auth.identities rows as shown above
   The hypothesis is that GoTrue's internal schema introspection cache on the branch became corrupted during the heavy direct-psql modifications, and a project restart does not fully reinitialise it. The main branch (which was never modified via direct psql) authenticates normally with the same password hashes and user records.