Internal (?) Auth Migration causes fail at launch (client_secret hash col missing in oauth_clients)
Encountered starting 10/13
Unsure if caused by us or supabase given this is a uni capstone project with inexperienced devs, there's a chance theres something hidden somewhere always but the nature of the error goes against it.
Our projects migrations and scan of all local/cloud repositories failed to find the shown migration but 2x related ones were found present in supabase's official Auth repo (1 for adjusting the Auth schema and the other for this failing migration itself)
Auth schema cannot be edited by us as known, and as this migr is not observable or editable by us we're at a loss on what to do to get our auth instance back up and running.
-- WILL FINISH GRABBING ITEMS
18 Replies
Script found in Supabase itself:
One of our running theories is that the clients table was created prior to a supabase migration triggering the same creation (202507311) which led to the cascading fail
But to my understanding the tables were already present so not sure how that one works out?
getting the same issue were you able to fix
Can you drop your ticket # here if still not resolved?
276590
I added it to the escalation list.
It appears a few projects did not get an migration file back in ... Aug.
Another thread here with a bit more info.
🙏 Thank you,
I’m part of the same team as OP. I have some doubts whether or not this issue is similiar with some of the other posts. This is our auth.schema_migrations table.
There’s a fair bit of context that hasn't been explained, since I was the one that was researching this problem and came up with this theory. We originally had a very similar problem last month on September 2. You view the error here. The specific error is “column deleted_at does not exist” caused by the migration script 20250731150234_add_oauth_clients_table.up.sql.
We were somehow able to fix this issue very quickly within the same day. I had no part in fixing the previous issue. The OP was the only one who was trying to fix this issue at the time. We also have the same issue that started October 3rd. The specific error this time around is “column client secret hash of oauth_clients does not exist” caused by the migration script 20250901200500_add_oauth_client_type.up.sql.
My theory is that we already had the oauth_clients table, but with the incorrect columns. There is only one entry here and it’s dated August 4th. You can also see the sql definition we have is incorrect. Here's the official supabase one.
What likely happened is we already had the oauth_clients table at or before August 4. Supabase or one of us caused migration scripts to run on September 2nd. “20250731150234_add_oauth_clients_table.up.sql” would’ve correctly created the oauth_clients table, but it didn’t since the table was already there. Since the columns were incorrect, we had the issue with the missing column. I assume we were somehow able to add this missing “deleted_at” column somehow. On October 3rd, Supabase or one of us caused migration scripts to run 20250901200500_add_oauth_client_type.up.sql. This also reference a column that does not exist.
Well either way your ticket is in to my contact.
It does seem like maybe a different migration issue, but I really have no idea what the real issue is and was just comparing the other user who was missing this file in migrations table.
Thanks, the fix I have suggested is deleting our auth.oauth_clients table, then reapplying the migration scripts from when it would correctly applied it.
Sorry above my paygrade.
haha mine as well... I'm just a college student doing this for a capstone project
Something happened to 1/2 dozen instances at least recently with the migrations.
I thought about just replacing the missing migration files from a good system and restarting.... but not sure what that might break.
I'm not sure why our auth schema was tampered with beyond what the migration scripts that supabase provided? I've asked my other team members and OP and they said you can't tamper the auth schema.
I think you could delete rows from that table.
But not sure.
You can modify data in general just not columns or tables alters in auth schema.
But seems something happened from Supabase side to me with this group of 4 to 6 that I know of (some could be repeats between forums).
That is a lot of this type of issue in a few days.
Here are all the migrations and what they do...
https://github.com/supabase/auth/tree/master/migrations