supabase-wrote: know when an update or delete did not save, and why

[lagudafuadtosin]

When row level security blocks an update or delete, Postgres matches no rows and supabase-js returns { error: null }.

My app said Saved on a task, but nothing was actually saved.

So I made one package with three parts:

• wrote(result): returns the saved rows, or throws with the reason.
• npx supabase-wrote find .: lists updates and deletes that cannot tell whether they saved, and fails CI on new ones.
• policies.sql: a read-only check that lists tables where updates silently do nothing, usually an UPDATE policy with no SELECT policy.

Tested against real Postgres and PostgREST.

https://github.com/lagudafuadtosin/supabase-wrote
npm: supabase-wrote

MIT. If it gets something wrong, let me know and I will fix it.

[cekuu35]

Nice — this solves a real gap: error: null with zero rows affected is the worst failure mode in the stack, and a lint that fails CI on new silent writes is the right shape.

One more silent case worth folding into policies.sql, because it's the sibling of your UPDATE-without-SELECT:

UPDATE with a qual but no with_check. A policy like for update using (auth.uid() = user_id) (no with check) lets the row be selected for update but rejects the write — again error: null, zero rows. And the mirror on INSERT: for insert with check (...) with no for select policy means the insert succeeds but the row is invisible to .select() right after — reads as "saved but gone."

The catalog query that catches both:

select tablename, policyname, cmd, qual, with_check
from pg_policies
where schemaname = 'public' and cmd in ('UPDATE', 'INSERT')
order by tablename;

Any UPDATE row with qual set and with_check null, and any INSERT without a matching SELECT's grant path, is a silent-write candidate.

Worth cross-linking: I maintain the symptom-index side of this family (fix-by-symptom map: https://dev.to/cekuu35/rls-not-working-fix-by-symptom-a-debugging-map-for-supabase-4gj9 ) — if you ever want to point supabase-wrote users at a fix walkthrough, it maps each symptom to the exact policy/grant fix. Complementary tools, same problem.

Good call shipping it as a lint (npx supabase-wrote find .) — detection at commit time is where this class actually gets killed.

[lagudafuadtosin]

thanks so much for reading it I appreciate that, but none of these are silent so I will keep them out of policies.sql

an update policy with no with check works fine because postgres uses the using rule for both, and if the check ever fails you get a real error, not silence (the live test in the repo shows this)

a plain insert saves the row, and insert with .select() and no select policy raises that same error instead of looking saved

the silent cases are where postgres cannot find the row at all, which is what the finder looks for

[cekuu35]

You're right on both, and the live test is the convincing part — I'll stop claiming those two. The with-check-omission case: since Postgres applies the USING rule to the new row when WITH CHECK is absent, it fails loudly, not silently. And insert-then-select with no select policy errors rather than returning empty — I verified against a live project.

That narrows the true silent class to exactly what your finder targets: no matching policy at all → zero rows affected, no error anywhere. Thanks for testing against real Postgres instead of arguing from docs — the repo shipping a live test is better evidence than my reasoning was. Following supabase-wrote now.

[FloatingPegasus]

I'm building Rewind for recovery of captured Supabase updates. One documentation addition I'd suggest: no-rows can also mean that an expected-version filter correctly rejected a stale edit, even when the row exists and the caller has access.

A disposable test case:

1. Read the same owned row into two clients at version 5.
2. Client A updates it with both ID and version 5 in the filter, advancing the version to 6 in that same UPDATE.
3. Client B tries its old version-5 update and requests the affected rows. Expect an empty result; independently read the row and verify A's values remain.

Every writer must advance the revision for this contract to hold. The empty result alone cannot distinguish stale revision, missing row and RLS filtering. I'd keep the generic no-rows result, add predicate mismatch to its explanation, and let the application's context choose the message. Don't automatically retry after removing the version filter.

This is a proposed test case, not a claim that I've run your package. PostgreSQL's Read Committed documentation explains the WHERE recheck behind it.

[lagudafuadtosin]

I totally agree with you, and thanks for the test case. The helper cannot tell the three apart from an empty result, so no-rows stays 1 reason. The message and the readme now say it in 1.0.8, with a note not to retry without the version filter.
row level security blocked it, the row does not exist, or another filter in the query did not match, like a version check.