[Bot] A failure midway through converting raw tracks deletes the tracks not yet converted #520

New issue

Open

opened 2026-09-06 03:03:28 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-09-06 03:03:28 +00:00

Contributor

Found while doing #393 (v4.3.0 phase 5), outside that lane's scope; same family as #399.

RecordingCog._process in bot/questboard_bot/cogs/recording.py converts each speaker's raw capture track ({session_id}_{user_id}_raw.16k-mono.s16le) into its WAV and, in a finally: block at the end, unlinks every remaining entry of raw_track_files. The normal stop path deletes each raw track as soon as it is converted, so on success the finally has nothing to do. But if the conversion loop raises partway (disk full, a corrupt track, an exception in the WAV writer), the finally still runs and deletes the raw tracks that were not converted, which is the only copy of that audio. The failure message the GM sees was reworded in #393 so it makes no promise about what is left on disk, but the loss itself still happens.

Expected: a failure in the conversion loop leaves the unconverted raw tracks in place, so #399's startup recovery (which treats leftover raw tracks as the signal that a recording never finished) can convert and hand them off on the next start, or an operator can. The cleanup should only remove tracks that have a WAV to show for them.

Acceptance:

A test that makes conversion fail on the second of three tracks asserts the third raw track still exists afterwards (and the first's WAV does).
The finally (or its replacement) removes only raw tracks whose WAV was written.
recover_interrupted_recordings picks the survivors up on the next start (existing behaviour; add a test if one does not cover this shape).

Found while doing #393 (v4.3.0 phase 5), outside that lane's scope; same family as #399. `RecordingCog._process` in `bot/questboard_bot/cogs/recording.py` converts each speaker's raw capture track (`{session_id}_{user_id}_raw.16k-mono.s16le`) into its WAV and, in a `finally:` block at the end, unlinks every remaining entry of `raw_track_files`. The normal stop path deletes each raw track as soon as it is converted, so on success the `finally` has nothing to do. But if the conversion loop raises partway (disk full, a corrupt track, an exception in the WAV writer), the `finally` still runs and deletes the raw tracks that were **not** converted, which is the only copy of that audio. The failure message the GM sees was reworded in #393 so it makes no promise about what is left on disk, but the loss itself still happens. Expected: a failure in the conversion loop leaves the unconverted raw tracks in place, so #399's startup recovery (which treats leftover raw tracks as the signal that a recording never finished) can convert and hand them off on the next start, or an operator can. The cleanup should only remove tracks that have a WAV to show for them. Acceptance: - [ ] A test that makes conversion fail on the second of three tracks asserts the third raw track still exists afterwards (and the first's WAV does). - [ ] The `finally` (or its replacement) removes only raw tracks whose WAV was written. - [ ] `recover_interrupted_recordings` picks the survivors up on the next start (existing behaviour; add a test if one does not cover this shape).

claude-bot referenced this issue

2026-09-06 03:03:53 +00:00

feat(bot): a self-diagnosing bot, a /record start that knows the session, and linking that names the way out (phase 5 lane B) #521

claude-bot referenced this issue

2026-09-06 03:12:47 +00:00

v4.3.0 build order: Product Surface in eight phases #514

claude-bot referenced this issue

2026-09-06 03:40:30 +00:00

[Bot] Fix /record start's broken session identity, unresponsive stop, and silent data loss on restart #393

claude-bot referenced this issue

2026-09-06 04:22:13 +00:00

v4.3.0 build order: Product Surface in eight phases #514