Delete RLS violations return 204 not 403

[reisepass]

Bug report

SQL/API Delete row-level security policy violations return 204 not 403 like with inserts.

Describe the bug

This may be a design decision but it is very unintuitive and significantly increases time to debug access control.

To Reproduce

1. Create a table where with no DELETE policy but RLS is enabled
2. Insert some data in the dashboard
3. Try to delete data from the JS client / CURL api
4. API will return 204 but nothing gets deleted in the DB

Expected behavior

When deletes fail do to RLS a 4xx http code should be returned specifically 403

[GaryAustin1]

This is expected behavior as discussed in this issue in postgrest-js:

https://github.com/supabase/postgrest-js/issues/307

This is probably more a documentation issue than a bug.

Moving to Postgrest-js for devs to decide on proper documentation if appropriate.

[Netail]

Same for inserting data, very confusing when debugging. GraphQL also started to get backlash due to only returning 200s, making it hard to debug

[pompep]

To detect RLS errors on update and delete, I check the response.count field. Something like:

const response = await client
  .from("table")
  .delete({ count: "estimated" })
  .eq("id", rowIdToDelete);

if (response.count !== 1) {
  // detected RLS error
}

seems like it works, but if someone has a better solution, please let me know

[soedirgo]

Closing as duplicate of #307 - the answer in that issue still applies.