Urgent SOS: My Supabase Project Thinks It's 2025/6/1 (SELECT NOW() is a Year Ahead, Breaking API Key Auth with 401s) #36087
Sajid357404
started this conversation in
Show and tell
Replies: 1 comment 3 replies
-
|
I checked the post number and it seems to be from this year... 2025. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment


Uh oh!
There was an error while loading. Please reload this page.
-
Hey Supabase Gods & Community!
I've hit a bizarre and critical wall with my project (ID:
sqhytxmfhxfkduhrfoln), and I'm pretty sure I've found the culprit – my project's database server seems to be living in the future!Here's the Lowdown:
SELECT NOW();in my SQL Editor, it spits out a timestamp from freaking 2025 (like2025-06-01 XX:XX:XX...). I've got the screenshot to prove this temporal anomaly.anonpublic key) are getting aniat(issued at) timestamp that's also in 2025. My latestanonkey, for example, has aniatlike1748769402– June 1st, 2025.401 Unauthorized. My app then logs an RLS violation, but the 401 is the real party pooper here, all because the keys aren't "valid yet."anonrole are golden. I've tested them directly in the SQL editor (SET ROLE anon; INSERT...), and they work like a charm when the role is properly assumed.The Damage Report:
This time warp means my app can't make any anonymous API calls. Development is dead in the water until my project rejoins us in 2024.
The Mission (Should You Choose to Accept It):
Can you fine folks at Supabase please take a look at the server hosting my project (
sqhytxmfhxfkduhrfoln) and give its system clock a good kick back to the present day? OnceSELECT NOW()reflects reality, my API keys should start generating with a properiat, and the 401s should vanish.Massive thanks for looking into this urgently! My project's future (and present) depends on it!
Cheers,
Beta Was this translation helpful? Give feedback.
All reactions