RLS INSERT Policy With WITH CHECK (True) Rejects All Writes On Supabase, Only Disabling RLS Resolves

Supabase's connection pooler/PostgREST layer caches prepared statements with RLS predicates evaluated at plan time. When auth.uid() is unset during initial plan preparation, the predicate user_id = auth.uid() is inlined as NULL = NULL (i.e., false), producing a deny-plan. Subsequent DDL changes (policy drop/recreate, WITH CHECK (true)) do not invalidate the stale plan because the connection pooler does not propagate catalog invalidations, so the old false predicate is reused even for new policies.

1. Create table public.event_registrations with RLS enabled. 2. Add INSERT policy: CREATE POLICY ... ON event_registrations FOR INSERT WITH CHECK (user_id = auth.uid()); 3. Authenticate as a user and attempt to insert a row with user_id = auth.uid() via supabase-js. 4. Observe ERROR: 42501: new row violates row-level security policy. 5. Replace policy with WITH CHECK (true) and retry; same error. 6. Execute a DO block setting LOCAL role authenticated and request.jwt.claims, then INSERT; same error. 7. Run NOTIFY pgrst, 'reload schema'; same error. 8. Disable RLS on the table; insert succeeds.

This workaround bypasses RLS for inserts into event_registrations. If the function is exposed to untrusted callers, it can insert rows for any user_id, defeating the intended RLS protection. Use with caution and restrict EXECUTE privileges. For rollback, simply DROP FUNCTION public.insert_event_registration; but be aware that the original direct INSERT will still fail until the platform bug is fixed or RLS is disabled. Consider re-enabling RLS after the platform update and reverting to direct policies.