error is always null if delete is not successful due to RLS policy

[danaoairuike]

Bug report

• [x] I confirm this is a bug with Supabase, not with my own application.
• [x] I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

There are 2 scenarios to reproduce the bug:

• either you do not have a RLS policy to allow delete at all
• either you do have a RLS policy to disable delete when some condition is met (mine is when a column value is true)

in both scenarios, the delete is not successful, and the error is always null.

It's very easy to reproduce the bug.

 const { error } = await supabase
              .from("my_table")
              .delete()
              .eq("id", id);

console.log(error);// the value is always null

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Go to '…'
2. Click on '…'
3. Scroll down to '…'
4. See error

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: [e.g. macOS, Windows]
• Browser (if applies) [e.g. chrome, safari]
• Version of supabase-js: [e.g. 6.0.2]
• Version of Node.js: [e.g. 10.10.0]

Additional context

Add any other context about the problem here.

[jonshung]

Can you try logging the error inside a then() callback? issue might be on postgrest-js's end Edit: Checking the return status might also be helpful, some responses from postgrest will return a null error

[danaoairuike]

Can you try logging the error inside a then() callback? issue might be on postgrest-js's end Edit: Checking the return status might also be helpful, some responses from postgrest will return a null error

the status is always 200

[GaryAustin1]

Postgres does not return errors when you don't meet select/using policies. It is like a filter was not matched which also does not error. Delete does not error for not finding rows to delete.

Using DELETE for a policy means that it will apply to DELETE commands. Only rows that pass this policy will be seen by a DELETE command. There can be rows that are visible through a SELECT that are not available for deletion, if they do not pass the USING expression for the DELETE policy.

In most cases a DELETE command also needs to read data from columns in the relation that it is deleting from (e.g., in a WHERE clause or a RETURNING clause). In this case, SELECT rights are also required on the relation, and the appropriate SELECT or ALL policies will be applied in addition to the DELETE policies. Thus the user must have access to the row(s) being deleted through a SELECT or ALL policy in addition to being granted permission to delete the row(s) via a DELETE or ALL policy.

https://www.postgresql.org/docs/current/sql-createpolicy.html

[netcamo]

Hi, I have encountered exactly same problem. At the moment I can not find a way to know if delete succeeded or not. Is there any workaround to check if it has been successful?

Thank you in advance!

[MJUrian-Learner]

any updates on this

[charlie-ttt]

Would like to know how you guys are currently check if the delete operation is successful.

I'm currently checking the if the value(s) length provided in the argument is same length as the result. Although.... this seems a bit cumbersome

const tagsToRemoved: string[] = []

const { data, error } = await supabase
  .from("profile_tags")
  .delete()
  .eq("profile_id", profileId)
  .in("tag_name", tagsToRemove)
  .select();

if (error) throw error
if (data.length !== tagsToRemoved.length) throw new Error("something went wrong")