Can't read tables with service role
I was developing a full blown API via edge functions locally, everything worked smoothly. I may have over engineered the function code, but i see no reason why it works locally but fails remotely.
Details: im using the latest supabase-js (2.54) both locally and remotely.
I have made custom rate limiting code, that reads values from the db for various actions that I can declare individually.
( i will continue in multiple posts on this thread)
49 Replies
I didn't want to repeat myself with CORS and generic error handling in every edge function, so I created a function wrapper that does some of that generic stuff
as u can see, it creates an admin supabase admin client here and then passes it down the wrapped function, though I assume that should give no problems
the rate limiting function reads the config on rate limiting rules by finding the appropriate row in app_config table like so
I am at a total loss of why it fails, especially since it works flawlessly on my local supabase instance
i imported the migration, so all values were present

most notably this function fails (though all rate limited in this way functions fail)
i double checked that the app_config table is not malformed. Locally, RLS policies were disabled since I was using the admin client to access it, but remotely i enabled read access for all for testing, and it still doesn't work
right now im thinking passing down the admin client is an issue? But code without this type of rate limiting works
I would love to find a place to keep looking for the bug in
project id: ayaldagjacwuwllsmefn
You don't need to post your project id here. This is a user helping user forum. I'll glance thru this later if no one else comes along.
Also you should state if you are using the new API KEYs or asymmetric JWT's.
>Also you should state if you are using the new API KEYs or asymmetric JWT's.
I'm using the old anon and service role jwt yeah
hmm could it be that my project has no way of using the old service jwts?
You mentioned you created an admin client but you haven't showed us how that is even created. Also you have a second client in your code which is using the anon key which could potentially mess with your admin client depending on how it was created.
just this

does creating an anon client invalidate the admin client?
You need to tell it not to use session and turn off some other features else both clients could end up sharing the same session. Example of how to create a service role client can be found here https://github.com/orgs/supabase/discussions/15860
thanks, this looks like it could be exactly the issue! It's too late to work on this, but I'll let you know if this fixes it when I wake up
does it make sense for it to work in a local instance without these options? Why is there a difference between local and remote behaviour?
I wouldn't know why there is a difference between the two.
alright, I guess we may actually know more if this does fix the issue, as it's not certain yet
In local you are unlikely sending the authorization header, whilst on hosted this is always sent to en edge function (well this was true when using the old api keys, not so sure if this is still the same with the new ones).
i was sending the authorization header with the jwt anon key
And I'm still using the old api keys, I didn't figure there's a new standard. I will move to them but only after I fix this issue
I'm not suggesting you move to them here, I'm just stating they work differently. You should read up on them before moving to them.
unfortunately this has not fixed the error or changed the behaviour in any way
okay i have made a test function that just tests the ability to do db queries

i get this error

im totally at a loss
are the old jwts deprecated now?
it would appear i can't make any db requests in the edge functions themselves, at least not with .from()?
If the apikey was wrong you would get an APIkey error.
Does your DB work from any sort of app at all?
Check the status of the instance on the home page.
Maybe restart the instance. That error sounds like PostgREST (the API) can't access its internal data from the db.
seems to be fine

didn't help
ill try doing it from the client library
oh and
The DB does work
HeidiSQL is able to connect to it via the pooler
Where are you getting that error message from?
I log the error here

it's the
error
objectthe tests table is just this

Take a look in the API Gateway log and see if there is any more info.

the raw log msg
There is no table name in the URL...
huhh
yeah that's very weird i didn't even notice
is my request in js bad?
this request alone should be enough for the correct api call , right?

wait
im confused
okay im not sure what was that , sent the request again and it's in there

seems correct
That looks fine.
Did you restart the instance?
yes
For some reason your PostgREST server is not working..
I've never seen anything useful in the PostgREST log but look there.
i was already thinking how convenient supabase is and then something always is supposed to break lol
did i mess up the db with a migration?
Do you have the API turned off and is public in the exposed schema list.
https://supabase.com/dashboard/project/_/settings/api
oh god it is
is it disabled by default?
No
But it is an option when you create the instance to turn it off.
wow, it works AHAHA
thanks so much!
what a stupid mistake
The error was not very useful either from them.
i suppose it makes sense - no schemas exposed for the public API
Your last error message was clear, that was when I realized to ask about the API being on. The one to your rest request was vague.
yep
many layers of indirection probably makes it hard to know for sure from the pov of postgrest
thanks a lot
this made me realize how bad my own error logging is, I obscured the actual error even further