A stalled or dead S3 at finalize used to mean the recording was simply lost — the upload was the only copy of the bytes. Now the local disk is the source of truth and S3 is a best-effort mirror with a catch-up sweep: - DebugRecordingCreate always writes the recording to a local spool under DataDir/debug-recordings/ (the dev layout), and when S3 is configured also streams a copy to the bucket. A committed upload removes the spool; any S3 failure — at open, mid-stream, or at commit — leaves the spool in place and is logged, never surfaced as a recording error. - main runs a salvage sweeper (15m interval) that uploads any spool idle for 15+ minutes and deletes it once committed. Active recordings are naturally skipped (their mtime advances with every write; wedged workers die to their watchdogs well inside the window). This also retroactively rescues the recordings stranded on production disks by the pre-#1209 bug — same layout, so they're just leftovers to sweep. - S3 object keys now use the same ":" sanitization as the on-disk layout, so a spool's path relative to DataDir IS its object key — that's what keeps the sweep a trivial walk. (No objects ever landed under the old raw-DID keys, so there's no migration.) - UploadWriter grows Abort so a failed mid-stream copy can discard its dangling multipart instead of leaving it for lifecycle rules. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>