supabase / storage / 40778436987

87%

push

github

fix: improve handling of writes prevented by database triggers (#1600)

## What kind of change does this PR introduce?

Bug fix

## What is the current behavior?

A trigger on storage.objects that blocks a write causes confusing
results. Uploads, copies and moves can fail with a 500 error. Uploads
that are not upserts do not notice the trigger until after the whole
file has been uploaded to storage. On versioned buckets, a trigger that
blocks updates causes a 409 "already exists" error. Moving an object in
a bucket without versioning returns a 404 even though the object exists.
A bulk delete on a versioned bucket can succeed without leaving delete
markers, so the objects disappear.

## What is the new behavior?

If a trigger blocks an object write, the request fails with an error
(`AccessDenied`). This applies to uploads, copies, moves, deletes and
bulk deletes, whether the trigger blocks an insert or an update. Nothing
is changed in the database when this happens. A bulk delete either
deletes every object or none of them. If the trigger is caught before
the file is uploaded, nothing is uploaded. If it is only caught at the
final write, the uploaded file is removed. If a write ever returns no
row for any other reason, the upload fails and the uploaded file is
removed.

### Known limitation

A move in a bucket without versioning can still return a 404 when the
trigger only blocks the calling user. This case looks the same as a row
hidden by an access policy, so it can't be distinguished.

8123 of 9867 branches covered (82.32%)

Branch coverage included in aggregate %.

52 of 52 new or added lines in 2 files covered. (100.0%)

13903 of 15508 relevant lines covered (89.65%)

916.49 hits per line