Error fixes / Lovable
Lovable
Lovable: the Supabase query returns an empty list
The request succeeds with status 200 and an empty array because no SELECT policy matches.
The error
[]
What it means
This one looks like missing data. The table has rows in the Supabase dashboard, and the Lovable page shows nothing. When RLS is enabled and there is no SELECT policy for the role you are using, Postgres returns zero rows and no error. The dashboard still shows rows because it does not use your user's JWT. Inserts may fail separately with a row-level security error, so you can see both symptoms in one app.
Fix
- In the browser network panel, open the request to the Supabase REST URL. A 200 with [] is this case. A 401 or permission denied is a different page on this site.
- Confirm you are signed in if the policy requires auth.uid().
- Add a SELECT policy that matches how rows are owned, often user_id = auth.uid(). Enable RLS if it is still off, rather than opening the table to everyone.
- Insert a row as that user, with the owner column set, and reload. You should see that row and not someone else's.
- If the table is meant to be public, write a SELECT policy that says so in SQL, using a narrow condition. Do not disable RLS to get the preview working.
Prompt
Fix prompt
A Lovable page loads with an empty list. The Supabase request returns 200 and [] while the table has rows in the dashboard. Do not turn off row level security. Add a SELECT policy so the signed-in user can read their own rows, and make sure inserts set the owner column to auth.uid(). If the page should show only the current user's rows, keep it that way. Tell me the policy and how to confirm with a signed-in session. Do not use the service role key in the Lovable frontend.
Questions
Why does the dashboard show rows the app cannot see?
The dashboard uses a privileged connection. The app uses the anon key and the user JWT, so RLS applies. An empty list with status 200 usually means no SELECT policy matched.
Is an empty list a network failure?
No. The request succeeded. Check the response body. If it is an error object, use the message. If it is [], look at SELECT policies.
People can insert but nobody can read. How is that possible?
INSERT and SELECT policies are separate. You can allow one and forget the other. Add the SELECT policy without widening it to every row.