Erreur 500 sur /auth/v1/token - "Database error querying schema"

[ecodigitnew-rgb]

Description :
L'API Auth standard de Supabase retourne une erreur 500 avec le message
"Database error querying schema" sur toutes les tentatives de connexion.

Le même compte fonctionne parfaitement avec une fonction RPC personnalisée
(auth_user_login), ce qui confirme que :

• ✅ L'utilisateur existe dans auth.users
• ✅ Le mot de passe est correct
• ✅ Les politiques RLS sont correctement configurées
• ❌ L'API Auth publique est défaillante

Le problème est reproductible à chaque tentative de connexion.

======== Informations à fournir ============

1. Logs d'erreur
   {
   "url": "https://mabcizxujioaicalhdvy.supabase.co/auth/v1/token?grant_type=password",
   "method": "POST",
   "status": 500,
   "response": {
   "code": 500,
   "error_code": "unexpected_failure",
   "msg": "Database error querying schema",
   "error_id": "019fc961-519b-76a1-a75d-e0b5d0a5301d"
   }
   }

2. Configuration

• Supabase version: (dernière version)
• Politiques RLS: activées et correctement configurées
• Utilisateur dans auth.users: confirmé
• Extension pgcrypto: activée

[GaryAustin1]

No idea what you details are as this is normally an English forum.

But database error on /token is almost always an auth.users trigger function you wrote failing or an auth hook you wrote failing.

You probably can get more info in the Postgres log on the actual error.

[cekuu35]

The most useful detail in your report is the one that looks like a side note: your own auth_user_login RPC works while /auth/v1/token does not.

Those two paths read the same rows. What differs is the role. Your RPC runs on the PostgREST connection (authenticator, then anon or authenticated), while GoTrue connects as supabase_auth_admin. So the failure is almost certainly a privilege or ownership drift on the auth schema rather than anything about your users, your passwords, or your RLS policies — which also explains why "RLS is correctly configured" is true and irrelevant at the same time.

Run this as postgres:

select c.relname,
       c.relowner::regrole                                        as owner,
       c.relrowsecurity                                           as rls_enabled,
       c.relforcerowsecurity                                      as rls_forced,
       has_table_privilege('supabase_auth_admin', c.oid, 'SELECT') as auth_admin_can_read
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'auth' and c.relkind = 'r'
order by 1;

select has_schema_privilege('supabase_auth_admin', 'auth', 'USAGE') as schema_usage;

Every row should be owned by supabase_auth_admin with auth_admin_can_read = true, and schema_usage should be true. Two specific ways this breaks:

• An owner other than supabase_auth_admin. Once ownership moves, the owner-bypass for RLS stops applying to GoTrue, and any policy on that table starts filtering the rows it needs.
• rls_forced = true on an auth table. Forcing RLS removes the owner bypass even when ownership is correct. Blanket "enable and force RLS on every table" scripts reach into auth more often than people expect.

If those all look right, then the other cause is the one GaryAustin1 pointed at, and it is worth checking directly rather than by elimination — a password grant updates auth.users (last_sign_in_at, refresh token rows), so a trigger that raises will surface as exactly this error:

select tgname, tgrelid::regclass as on_table, pg_get_triggerdef(oid)
from pg_trigger
where not tgisinternal
  and tgrelid in ('auth.users'::regclass, 'auth.identities'::regclass, 'auth.sessions'::regclass);

-- and any column added to auth.users that GoTrue does not know to populate
select attname, atttypid::regtype as type, attnotnull
from pg_attribute
where attrelid = 'auth.users'::regclass and attnum > 0 and not attisdropped
order by attnum;

A NOT NULL column with no default added to auth.users produces the same 500, because GoTrue's insert or update has no value for it.

Your error_id (019fc961-519b-76a1-a75d-e0b5d0a5301d) is searchable in Logs Explorer under Auth logs, and the matching Postgres log line for that minute carries the real SQL error. That is the shortest route to the answer — everything above is how to fix what it tells you.

---

En français, en résumé : le fait que votre RPC fonctionne et que /auth/v1/token échoue est le point décisif. Les deux lisent les mêmes lignes ; ce qui change, c'est le rôle. GoTrue se connecte en tant que supabase_auth_admin, votre RPC non. Vérifiez donc le propriétaire et les droits des tables du schéma auth avec la première requête ci-dessus : toute table dont le propriétaire n'est pas supabase_auth_admin, ou dont rls_forced vaut true, est la cause. Sinon, regardez les triggers sur auth.users et les colonnes NOT NULL ajoutées à cette table.