A failed run's audio clock no longer restarts on a write to its session (#798) #992
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/798-audio-received-at"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #798.
The problem
#791 anchored a processed session's audio retention on the write-once
audio_processed_at. A session whose processing has only ever failed had no such stamp and still counted fromsessions.updated_at, which moves on any write to the row. Erasing a member's recording from a failed session adds a note to the row, so the erase restarted the clock for everyone else's audio: a privacy control causing more to be kept.The fix
sessions.audio_received_at, a nullable timestamp, written once where the bot's upload is accepted (POST /api/bot/sessions/{id}/audio). A re-upload or a retry does not move it. Nothing in the bot API's shape changes, so there is no contract bump.audio_retention_anchor, the one place the anchor is computed, which the preview and the sweep both use) now takesaudio_processed_at, then for a failed runaudio_received_at, andupdated_atonly as the last fallback for a row carrying neither.a798c0d1e2f3on11d4e5f6a7b8. It adds the column and backfillsaudio_received_at = updated_atfor rows that hold audio and have neitheraudio_processed_atnortranscript_updated_at. Those are exactly the rows that counted fromupdated_atbefore, so nothing is caught earlier or later on upgrade day. Downgrade drops the column.The two other places that set a session's audio path (Admin's retry and the session page's retry) re-queue audio already stored, so they are rightly left alone.
Tests
updated_at, leaves processed rows alone, downgrade drops the column, and it is the single head.🤖 Generated with Claude Code