After moving to the new non-JWT sbsecret key format, REST calls authenticated with the service-role key intermittently return 401 with proxystatus PostgREST and error PGRST303 ("JWT issued at future"). The odd part: the client only ever sends the opaque sbsecret_ key, never a JWT, so the usual "clock skew on a freshly-issued Auth JWT" explanation does not apply. The same request retried about 1.4 seconds later succeeds, and the pattern fires in bursts for several users. Moving the deployment region closer to the project region did not change it, and failures came through Cloudflare colos already local to the project region.

This is transient clock drift between Supabase's own backend services, not a client-side bug. With the new opaque key format, the gateway exchanges your sbsecret key for a short-lived internal token minted with the gateway node's own clock before forwarding it to PostgREST. If that internally-minted token's iat lands just ahead of the PostgREST/Postgres node's clock by more than the leeway window, you get PGRST303 — and there is no client-side fix, because the token being judged was minted by Supabase's gateway. The intermittent fail-then-succeed signature (occasional requests through one slightly-behind node) is the classic fingerprint. The reporter confirmed it cleared on its own after about a day. As containment, retry with backoff (300ms and 900ms retries were used on the thread). If it persists, escalate to support with the decisive evidence: several failing requestid/traceid pairs immediately adjacent to a succeeding retry for the same key and route, plus the gateway version and origin_time — that lets the team match the internally minted JWT against their own node clocks. Source: https://github.com/supabase/supabase/issues/49655