Before, the first error anywhere in the upload loop (e.g. R2's InvalidPart rejection at the first 10-minute rollover) killed the loop for the rest of the stream: one error line, then segments backed up silently and nothing more was recorded or logged. Production showed exactly this signature — one "started S3 multipart upload …-1.m4s" per stream, one InvalidPart ~10 minutes later, then silence. Now the loop recovers: the broken object is aborted (so the backend doesn't hold its parts) and abandoned with a loud log including the key and how many bytes are lost, and the next segment starts a fresh object. One bad object costs a gap in the recording instead of the whole stream. Abandoned objects never get RecordComplete, so finalize's completed_at-only query skips them naturally. Only the final completing flush still surfaces through Close — there are no more segments coming to recover with. A failure with no object in flight (CreateMultipartUpload itself) logs the dropped segment explicitly. The recording gate also gets audibility, after today's debugging session: - "live recording disabled for streamer" is promoted Debug -> Info; it fires once per stream session and is the answer to "why does this streamer have no recording?" - S3-not-configured gets a Debug line (runtime-flippable; Info would be noise in the no-S3 dev default) - a failed initial livestream-URI resolve now logs a Warn instead of being swallowed, and "S3 upload enabled" carries the repoDID Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>