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.