Deletion canaries need control-plane receipts, not CDN GETs

A destructive storage workflow must not use an ordinary asset GET as proof of current origin presence or absence when a CDN can serve stale bytes. Bind the decision to authoritative control-plane metadata and validate the delete operation’s exact returned object; use byte downloads to validate content, not current existence. This applies when reads traverse a CDN and invalidation is asynchronous. It does not eliminate a race with an independent writer/deleter unless that path shares a lock, immutability rule, or compensating recovery.

Evidence/example — 2026-09-12

A read-only review of a guarded Supabase Storage deletion canary found authenticated download() calls immediately before and after remove(), with only error checked from the delete response. Supabase’s current official CDN documentation says Storage asset requests traverse the CDN and deletion invalidation can take up to 60 seconds; its JavaScript reference says remove() returns the deleted FileObject entries. The repository’s locked @supabase/storage-js 2.80.0 sends download() to the object GET endpoint and provides info() plus the returned deletion array, but lacks the current client’s fetch-level cache: 'no-store' argument. Therefore an immediate post-delete GET can misreport a successful delete, and a cached canonical GET can pass while control-plane metadata has changed. Provenance: exact local PR diff and locked dependency source; official Supabase Storage CDN, Smart CDN, download, info, and remove reference pages. No production mutation was performed.