fix(webapp): each "keep the audio" choice means what it says (#834, A1/D179) #860
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/834-retention-semantics"
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 #834. This is the owner's A1 answer (D179).
Behaviour, before and after
trash_after_processing→trash_after_approval)apply_post_processing_audio_retentionis now a documented no-op.delete_after_processing,trash_after_processing) are normalised on read. There's no migration; the new name is written on the next save.e2e seed
The J5 fixture's campaign-level override only existed to work around this bug, so it's removed; the default now does what J5 needs. J5 needs its CI run to confirm this.
Tests
test_retention.py. Two approval regressions intest_sessions.py(retain_daysandretain_indefinitelyuntouched by approval).It adds no
Depends(get_db). It merges cleanly with main, #854 included.🤖 Generated with Claude Code
The default mode now bins audio when the GM approves the summary, not the moment process_audio succeeds — apply_post_processing_audio_retention is a documented no-op, and the nightly sweep's "already transcribed" catch becomes "already approved" (Session.content_approved_at). "Keep for N days" and "Keep it" no longer get overridden by approval: POST /sessions/{id}/approve only trashes audio under trash_after_approval now, and the review tab's audio_bin_days only appears when approving would actually bin something. A failed run keeps its usual debug window regardless of mode. Renamed the stored mode trash_after_processing -> trash_after_approval, with delete_after_processing and trash_after_processing both read as legacy spellings (settings_service, exactly as #427 did). No migration. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>