supabase / storage / 40950999542

87%

push

github

feat: improve lifecycle log accuracy and support object versioning operations (#1555)

## What kind of change does this PR introduce?

Feature

## What is the current behavior?

Lifecycle logs and webhooks do not reliably reflect what happens to an
object, and usage tracking is built on metadata.size, which breaks down
for operations that do not actually change stored bytes.

The lifecycle event logs have some general issues:

- `ObjectCreated:Put` / `ObjectCreated:Copy` does not include the size
of the replaced object when overwriting an existing object which makes
accurate usage tracking impossible
- Lifecycle logs are not emitted if webhooks are disabled for the
tenant, or if no webhook URL is configured
- Logs are emitted in worker job which can cause duplicate entries if
the job is retried
- Object version is not included in top level log output making it hard
to reason about / search (it is already in a stringified payload field)

Additionally, object versioning introduces its own issues:

- Deleting or moving an object by its exact version can silently make an
older version current again. It never emits a log or webhook, so the CDN
and audit trail had no way to know the live content of a key had changed
- Bulk delete and ObjectAdminDeleteAllBefore sent webhooks before the
delete transaction committed, so a webhook could fire for a delete that
later rolled back
- The `oldObject` field on `ObjectCreated:Move` does not include the old
object's size, so there is no way to tell how many bytes a move actually
changed at the source (byte change was always 0 before object
versioning)
- A same-path move writes the destination before deleting the source, so
the delete can find nothing. This double-queues cleanup. Discovered in
testing because it skews bytesChanged

## What is the new behavior?

- Every storage operation emits a log, including promotion
- Each log includes `bytesChanged`, the net bytes added or removed,
which can be summed to get usage st... (continued)

8183 of 9922 branches covered (82.47%)

Branch coverage included in aggregate %.

62 of 66 new or added lines in 7 files covered. (93.94%)

13976 of 15573 relevant lines covered (89.75%)

1223.78 hits per line