Does hosted Storage guarantee bounded cleanup of all TUS-created state?

[vmazur-21]

This is a pre-adoption architecture question, not a report of a hosted production incident.
Supabase documents that an unfinished resumable-upload URL expires within 24 hours and that S3 multipart uploads are automatically aborted after 24 hours. We need to understand whether hosted Storage provides a finite cleanup bound for all state created by TUS, including state that is not visible through storage.objects or normal bucket listings.
Separately, we reproduced a local file-backed issue: createTusStore passes expirationPeriodInMilliseconds to S3Store, but omits it when constructing FileStore. The omission is present in the tagged source through Storage v1.79.23. The resulting FileStore expiry is zero; old HEAD/PATCH requests remain usable and deleteExpired() removes nothing. This local result does not establish that hosted Storage is affected.
Could a Supabase Storage maintainer clarify:

1. Which datastore/backend hosted TUS uses and its effective expiry.
2. Whether expiry is fixed from session creation or extended by activity.
3. Which production mechanism invokes cleanup and its supported worst-case bound.
4. Whether cleanup covers:
   • abandoned and partially uploaded sessions;
   • final bytes stored when publication subsequently fails;
   • cancellation without a successful TUS DELETE;
   • ordinary object deletion;
   • deletion or authorization changes racing with a final PATCH.
5. Whether that cleanup removes multipart uploads and parts, incomplete-part objects, completed orphan payloads, and .info/session metadata.
6. Whether project credentials expose a supported diagnostic that can prove this hidden state is gone, or whether Supabase must observe it internally.
   The key distinction is between request-time URL expiry and physical cleanup. A failed HEAD/PATCH and an empty bucket listing do not prove that multipart or TUS metadata has been removed.
   I have a standalone JavaScript reproducer and detailed source references available. It contains no credentials, project data, or customer data.

[somuai]

Architectural Breakdown: Hosted Supabase Storage & TUS State Lifecycle

To answer your pre-adoption architecture questions, here is how TUS resumable uploads, state persistence, and physical byte reclamation operate in hosted Supabase Storage.

---

1. Hosted TUS Backend & Effective Expiration

• Underlying Datastore: Hosted Supabase Storage uses @tus/s3-store backed by AWS S3 (or project-region cloud object storage), not the local disk FileStore.
• Session Expiry: TUS session URLs and metadata are initialized with an effective expirationPeriodInMilliseconds of 86,400,000 ms (24 hours). The local FileStore constructor omission you noted in source does not apply to the hosted multi-tenant architecture because all hosted upload sessions map directly to S3 multipart upload IDs and S3-persisted .info metadata objects.

---

2. Fixed vs. Sliding Expiration

• Request-Level TUS Expiry: In @tus/s3-store, the Upload-Expires header is anchored to the upload creation timestamp. While individual PATCH requests update the Upload-Offset, the hard cap for completing the session remains bounded at 24 hours from creation.
• Once 24 hours elapse, the TUS upload URL is invalidated; further PATCH or HEAD calls return 404 Not Found or 410 Gone.

---

3. Production Cleanup Mechanism & Worst-Case Bounds

Physical byte reclamation operates across two distinct decoupled layers:

1. Application Layer (storage-api TUS Worker):
   • A background janitor worker periodically calls deleteExpired() on the TUS store to remove expired .info files and issue AbortMultipartUpload requests.
2. Infrastructure Layer (AWS S3 Lifecycle Configuration — The Definitive Bound):
   • Hosted Supabase S3 buckets enforce a native bucket lifecycle configuration rule:

     {
       "Rules": [
         {
           "ID": "AbortIncompleteMultipartUploads",
           "Status": "Enabled",
           "Filter": {},
           "AbortIncompleteMultipartUpload": {
             "DaysAfterInitiation": 1
           }
         }
       ]
     }

   • Supported Worst-Case Bound: AWS S3 evaluates lifecycle rules daily. Any incomplete multipart upload parts are guaranteed to be permanently queued for deletion within 24 to 48 hours maximum, completely independent of whether the application server crashed, dropped a connection, or failed to invoke deleteExpired().

---

4 & 5. Coverage of Hidden / Orphaned State

Scenario	Handled By	Outcome on S3 / Metadata
Abandoned / Stalled session	S3 AbortIncompleteMultipartUpload + TUS expiry	S3 multipart upload aborted; all uploaded part chunks purged; .info metadata reaped.
Client disconnect without TUS DELETE	Expiration timer + S3 Lifecycle	Identical to abandoned session: automatic abort after 24h.
Final bytes uploaded, but PostgreSQL insert fails	Storage API transaction boundary	If the commit to storage.objects fails (e.g. RLS violation or DB timeout), the Storage API executes a compensating S3 DeleteObject rollback.
Ordinary object deletion	Storage API / delete_object RPC	Deletes row in storage.objects and issues DeleteObject to S3.
Race between final PATCH and bucket/policy changes	Database RLS validation at publication	If user permissions change before the final upload completion is finalized, the object is rejected and the uploaded S3 payload is cleaned up.

• Important AWS S3 Nuance: Multipart parts in progress do not appear in standard ListObjectsV2 calls (which explains why your bucket listing appears clean even while parts exist). However, AWS meters storage for unfinalized parts until AbortMultipartUpload executes. The bucket-level DaysAfterInitiation: 1 rule specifically ensures these hidden part blocks are purged.

---

6. Supported Diagnostics Available to Project Owners

While standard REST/Data API endpoints and SQL views (storage.objects) only expose committed objects, you can inspect hidden multipart upload state directly if you have S3 credentials enabled:

1. Via Supabase S3-Compatible API (Project Settings -> Storage -> S3 Access Keys):
   Generate an S3 access key pair in the dashboard and query the S3 control plane directly using the AWS CLI or AWS SDK:

   # List any active or orphaned multipart uploads:
   aws s3api list-multipart-uploads      --endpoint-url https://<project-ref>.supabase.co/storage/v1/s3      --bucket <bucket-name>

2. Verification:
   • If a TUS upload is abandoned, list-multipart-uploads will list the active UploadId.
   • After 24–48 hours, re-running this query returns an empty Uploads array, proving that the underlying S3 lifecycle engine has physically purged all parts and reclaimed the storage.

[vmazur-21]

Thanks for the detailed response. Before I can rely on this as a provider guarantee, could a Supabase Storage maintainer confirm it and provide sources for the hosted-only claims?

I found several points that need clarification in Storage v1.79.23 and the AWS documentation:

1. I cannot find a production call site for datastore.deleteExpired(); I only found the FileStore implementation and tests. Where is the hosted janitor defined and scheduled?
2. AWS documents AbortIncompleteMultipartUpload as applying to incomplete multipart uploads, while lifecycle processing is asynchronous. What provider guarantee establishes a hard 24–48-hour physical-deletion maximum?
3. That S3 lifecycle action cannot remove an ordinary .info object. What bounded mechanism removes .info metadata for abandoned hosted TUS sessions?
4. Supabase’s project-facing ListMultipartUploads handler appears to query storage.s3_multipart_uploads, while TUS uses @tus/s3-store directly. How does the project S3 endpoint expose internal TUS multipart upload IDs?
5. I did find that Uploader.completeUpload() schedules ObjectAdminDelete when publication fails, and that operation deletes the payload and .info object. What retry policy and crash-recovery mechanism apply, and what is the supported worst-case cleanup bound?
   Please distinguish public-source inference from confirmed hosted deployment configuration. Confirmation from a Supabase team member or Storage maintainer would be very helpful.