GaryAustin1

You are not likely to reach Supabase on this topic thru discussions. Maybe an issue in that repository. You could try support but not clear they will take this up either. You mainly get other users here in discussions.

You will have to wait on support for this one.

You will have to wait for support to get to it. Github Discussion is not monitored by staff. Seems like based on ticket number not that old yet to be considered a lost ticket. Free can be several days.

Have you tried project restart from General Settings? Otherwise file as support ticket.

You should look thru old emails from Supabase for the project. Try logging in with a chatGPT account with that email. If project was created in Vercel/Bolt/Lovable there would be no Supabase.com dashboard. The only way you are not in the correct account is if you have team members on the org as owner and they dropped you as owner. support@supabase.com otherwise and expect a long wait. Better to find the real account.

Sorry I don't use these methods myself so have to feel for work arounds without "googling".

You would need to have your own intermediary function to convert the battle.net info to the "standard" format Supabase expects. There are no hooks that I know of.

If you decided to include user info in the logs then you would need to discuss with SB as to where that is stored. Last I checked they were using BigQuery for that service and no idea about colocation.

The logs contain NO data from DB operations or Auth operations. REST logs only have user ids. Look at the Gateway logs and the Auth logs. Only you could decide to log info from functions or turning on full Postgres logging (which they warn is also a major performance and very soon billing issue).

The backups would stay in the same data center. Unless you generate logs with user info they would not be any in the logs (not sure the logs are regional or not as SB uses providers for log storage). Auth runs on your server instance with your database so that is fine also. Don't think there is other processing involving user data involved except s3 storage files which also should be in same data center. No idea if Supabase has given formal notice of this or not and you won't likely get an official response here.

There should be no restrictions on adding policies with SQL. The SQL editor adds them just fine This shows using SQL to create policies. /docs/guides/storage/security/access-control Creating restrictive policies should be doable but more complicated because of the way they are handled in Postgres. You have to have permissive policies first and then you use restrictive policies to reduce access. This seems like it would be especially complicated with buckets involved as all policies are on the same table and just use where clauses to apply to different buckets. I would just use permissive policies to only allow storage access to service_role if that is what you want. Anon and authenticated do not have access by default unless you allow them.

Two AI's say the Blizzard endpoint is not returning keys in a json array required by 7517 standard and so Supabase is complaining about that. Note I did not give your error and both actually seem to have polled an endpoint to determine the malformed data. There are no settings on this. Could not find any issue or comments on the web though at all.

https://x.com/supabase/status/2109630227085168640

If that was the only method you implemented then you are likely locked out unless Supabase support can get you back in. Documented policy is they can't and you should have a backup method turned on. They have helped Pro users get back in with billing info. Unless you have access to CLI or Management API with keys you might not get back in. Only the account security group can help with this at support@supabase.com. Expect a multi week wait.

I assume this is Free plan based on you on you mentioning pause. Free plan has no SLA and especially over the weekend I would not assume the ticket is lost. I put in our informal queue but all that does is make sure you your ticket is not lost. There is no escalation.

You need to stop all activity from your app and wait many hours for disk i/o burst to rebuild then try restart again. Or you need to upgrade to Pro and Micro size which gives you more disk i/o. Support will likely be days and they may just say you need to upgrade as you have hit the i/o warning. Only you can decide if this is temporary or not based on your growth rate or what was going on when this happened. The API Gateway logs and charts might be useful for that.

If it is still running then you are likely using the wrong method to log in. If it was created from Vercel you need to use their dashboard. Otherwise you need to find old emails from Supabase to determine the email associated with the project. If that does not help you find the method (email or proper github account) then use that email to create a chatGPT account and log in with that.

You are very unlikely to get roles added to Auth schema because future migrations might break or reset them. The example above creating a new function is workable. You could also grant service_role or authenticated role to your role depending on what it does.

You should be in the right queue now. The employee suggested you try chatGPT login in if you have an account still working with the same email as the Github.

I added it to the informal queue we have. All that will do is make sure you are in the correct queue internally (you likely are already). The account group though is running 2 weeks even for Pro users though last I saw someone report when they got answered.

If you install PostGIS in the default extensions schema and not public it is protected from API access.

You can't use email login if account is created with an OAuth provider. Are you sure the chatGPT and Github primary email are the same? Try a different device. No other reports of a similar issue right now.

Does the key working on a database table from the REST API? Check the storage log for errors. No other reports like this that I've seen.

Postgis is supposed to be installed in the extensions schema. That is the default dashboard setting.

Those endpoints all work for me on my project using apikey with the sb_secret_... key. On the list one you do need to add the body with something like `{"prefix":"","limit":100,"offset":0,"sortBy":{"column":"name","order":"asc"}}`

If you are using sb_secret_..... then you only put that in the apikey header if you are doing direct API requests. You can't put it in the authorization header.

You should access a table from from the rest/v1 endpoint with this jwt for both apikey and authorization (with bearer) header so see if valid and going to the correct project. The management API might still show a legacy jwt even if you have turned off legacy jwt support in the dashboard. Check your dashboard settings.

Have you tried that service role key with the database REST API? Not sure what the JWKS endpoint has to do with legacy keys. Did you revoke the legacy keys?

You need to file a support ticket.

There is no escalation for these. I've not seen that email link before but maybe you found it somewhere. abuse@supabase.com is the normal email for banned accounts.

There is no escalation ability even by staff (I'm not).

If lovable cloud there won't be a supabase dashboard for it. If you signed in with github 2 weeks ago it would create a new empty supabase account with the primary email from github. You can check the email the account is using in account settings under your user icon top right, but with chatGPT logging into same one I'll assume that is the email for THIS account. So the org/project is in another email linked account or is Lovable cloud and there is no supabase.com access. I can also file this in an informal queue as a lost ticket, but these almost always end up being in wrong account.

Accounts are associated with email not by Github account. If the project is running then it is in an account with another email OR in Lovable/Bolt/Vercel and not available from the SB dashboard. Check your email history to confirm the exact email notices where being sent to. If you have CLI or Management API access still there are commands to show the org email members. Do you have teammates on the org? If so and one is owner they could also have removed you.

You will have to wait on your support ticket if Pause/Restore, restart did not resolve it.

Check upper right for Install Integration <img width="1511" height="647" alt="image" src="https://github.com/user-attachments/assets/3969368a-09c9-45ee-ab99-ddcf1fa26ea7" />

You need to enable webhooks in the integrations tab.

Probably was this dashboard permission issue... Should be resolved. https://status.supabase.com/incidents/ftwdxhst1yns

Support will need to help or in most case upgrading to Pro withe more disk space or then the included micro instance with more resources resolves it. This seems to occur after an SQL request that is too compute/disk intensive for a nano project.

You will need to wait on the infra team.

There is no auto restart. You'll have to wait on support or upgrade.

If restart does not help (unlikely) then your choice is wait for support or upgrade to support (larger disk) and free including micro to pick up a new hardware instance.

Check the storage log and Postgres log around the time of the request to see if it is an RLS error. Remember ALL polices on storage.objects run (OR'd together) and not just any you have in the bucket policy UI (that is just for convenience).

This has occurred in the past and was an RLS policy. Check your storage logs for details on the error. ``` Resolved on our side. Posting the root cause for anyone hitting this in the future. Cause: a SELECT policy on a public table queried itself in its USING clause: CREATE POLICY ... ON group_chat_members FOR SELECT USING (EXISTS (SELECT 1 FROM group_chat_members m2 WHERE ...)); Postgres rewriter expands all permissive policies for the role at plan time, so even uploads to OTHER buckets that didn't logically need access to this table got killed during the rewrite phase with 42P17. Storage server caught it as "schema is invalid or incompatible" → returned 400 to the client. Fix: replaced the self-referencing EXISTS with a SECURITY DEFINER helper function that bypasses RLS for the membership check. All buckets uploading correctly now. ```

You have already been helped by a person in support. User mods and even employees can't move things any faster when you are already in the specific group queue. You are in line with everyone ahead of you. I've never seen them estimate live time frames. Their target is 1 to 2 days from ticket on Pro, but it is longer coming out of weekend and there is no SLA.

This usually means you tried to use the email to soon after creating and it bounced. You might try chatGPT with that login (not sure it will work if email is marked inactive or not as account may not have been set up). Otherwise you need to contact support@supabase.com. This won't get resolved from Github.

You should try another browser or device. Also if you know your primary Github email (which it seems you do) try a chatGPT account with same email. That will work with Github signups. Email/password will not. Otherwise support@supabase.com but the account group is taking over a week right now.

I have no idea. I've only seen one or two people ask for contact in Discord and not heard back on if they got a response and when. These discussions are mainly users helping and not monitored regularly by staff.

You should try a restart from general settings. Otherwise contact support. This won't get resolved from Github as no one can access your project.

What region are you in (not your instance)? Had a few Discord reports from Singapore area. Try another region from a VPN. USA VPN has worked for some of those from Singapore. No idea if a network provider, vercel or SB.

Not sure are replying to the AI response or not. No one will resolve this from Github. You will have to wait for support if you did not create it with Vercel. If created with Vercel (or some other partner of Supabase) then typically they have a dashboard on their end you log in from. The message usually means that.