I am experiencing a persistent Row Level Security (RLS) error (403 Forbidden / Postgres code 42501) when trying to INSERT a row into a specific table (processo_assembleia) using the Supabase JavaScript client library. This happens even though the only applicable RLS policy for INSERT on this table for the authenticated role is WITH CHECK (true).

Crucially:

1. Running the exact same INSERT statement directly via the Supabase SQL Editor (using SET ROLE authenticated and SET request.jwt.claims) succeeds.
2. Disabling RLS entirely on the processo_assembleia table allows the INSERT operation from the frontend client library to succeed.
3. Network analysis confirms the frontend request includes the correct apikey and Authorization: Bearer <JWT> headers.
4. Analysis of the JWT payload confirms it has the correct sub (user ID), role ('authenticated'), and is not expired.

This suggests an issue with how the RLS check is evaluated for API requests when RLS is enabled, despite the policy logic being simply true.

Steps to Reproduce

1. Enable RLS on a table (e.g., processo_assembleia).
2. Create a simple RLS policy for INSERT for the authenticated role with the condition WITH CHECK (true) and ensure no other INSERT policies exist for this table.
3. Authenticate a user (in my case, using Google OAuth via @supabase/supabase-js).
4. Attempt to insert a row into the table using the client library (supabase.from('processo_assembleia').insert(...)). Ensure the payload includes a column referencing the user ID (e.g., criado_por_id: user.id).
5. Observe the 403 Forbidden / RLS violation error in the network response and console.
6. Disable RLS on the table and repeat step 4 - the insert now succeeds.
7. Execute the insert via SQL Editor using SET ROLE authenticated; SET request.jwt.claims = '...'; INSERT INTO ...; RESET ROLE; - the insert also succeeds.

Expected behavior
The INSERT operation via the client library should succeed when RLS is enabled because the WITH CHECK (true) policy should always evaluate to true for an authenticated user.

Actual behavior
The INSERT operation fails with a 403 Forbidden error and a PostgreSQL error code: '42501', message: 'new row violates row-level security policy for table "processo_assembleia"'.

Screenshots and Logs

1. RLS Policy List (showing only the relevant policy for INSERT):

• *
• *!"Confirming only one INSERT policy exists for authenticated role."

2. RLS Policy Definition (showing WITH CHECK (true)):
   • 

• *"Policy details showing WITH CHECK (true) and empty USING expression."

3. Successful SQL Editor Test:

   • 
   • "Executing the insert via SQL Editor with simulated auth context succeeds:"
     SET ROLE authenticated;
     SET request.jwt.claims = '{"sub":"791ea193*************", "role":"authenticated"}';
     INSERT INTO public.processo_assembleia (
     condo_id,
     criado_por_id,
     data_assembleia_prevista,
     data_assembleia_primeira_chamada,
     data_assembleia_segunda_chamada,
     formato,
     pauta,
     status,
     tipo_assembleia,
     titulo
     ) VALUES (
     10463,
     '791ea193-****************',
     '2025-05-03',
     '2025-05-03T19:30:00',
     '2025-05-03T19:50:00',
     'Presencial',
     '["Aprovação da última ata", "Aprovação da última ataasdasd", "sadasd"]',
     'Reservada',
     'AGO',
     'Nova Assembleia'
     );
     RESET ROLE;

4. Failing Frontend Network Request:

   • *

   • *"Network tab showing the failing POST request with 403 status and presence of Authorization + apikey headers."

5. Console Error Message:

   •   {
         "code": "42501",
         "details": null,
         "hint": null,
         "message": "new row violates row-level security policy for table \"processo_assembleia\""
       }

6. Decoded JWT Payload:

   • *"Decoded JWT payload from the failing request (verified via jwt.io):"

   •   {

"iss": "https://[PROJECT_REF].supabase.co/auth/v1",
"sub": "[USER_ID]",
"aud": "authenticated",
"exp": 1745966186,
"iat": 1745962586,
"email": "[USER_EMAIL]",
"phone": "",
"app_metadata": {
"provider": "google",
"providers": [
"google"
]
},
"user_metadata": {
"avatar_url": "[AVATAR_URL]",
"custom_claims": {
"hd": "[USER DOMAIN]
},
"email": "[USER_EMAIL]",
"email_verified": true,
"full_name": "[USER_NAME]",
"iss": "https://accounts.google.com",
"name": "[USER_NAME]",
"phone_verified": false,
"picture": "[AVATAR_URL]",
"provider_id": "100159466417968246758",
"sub": "100159466417968246758"
},
"role": "authenticated",
"aal": "aal1",
"amr": [
{
"method": "oauth",
"timestamp": 1745962586
}
],
"session_id": "[SESSION_ID]",
"is_anonymous": false
}
```
* Texto: "Note: The exp timestamp (1745966186) was verified to be valid (not expired) at the time the request failed."

System information

• OS: Windows 11 and macOs15
• Browser: Edge 135.0.3179.98, Arc 1.91.2
• Version of @supabase/supabase-js@2.49.4
• Version of Node.js 22.15.0
• Framework: [React, Vite, Lovable.dev]

Additional context

• "The issue occurs specifically when RLS is enabled on the table."
• "No other RLS policies exist for INSERT on this table."
• "No relevant database triggers seem to be involved (checked handle_updated_at trigger/moddatetime function)."
• "User authentication is done via Google OAuth."
• "Possibly using Lovable.dev framework, but the issue seems tied to the Supabase RLS evaluation itself given the network trace and JWT validity."