You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Backfill existing sound files to generated names, as a resumable command #991
Follow-up to #699. #982 makes new sound uploads land at sounds/<uuid>.<ext>, but says nothing about the rows already in the database, which still point at files stored under the name their uploader chose. Those are the ones actually exposed today.
#699 asks for "a migration to rename all the objects in the current database". This issue proposes doing it as a resumable management command instead.
Describe the design issue(s) you have identified in the code
A data migration is the wrong shape for this work:
It renames live objects in S3. A run that dies halfway — a network blip, a throttle, a deploy timeout — leaves rows pointing at keys that no longer exist, and a migration cannot be resumed from where it stopped.
It runs inside the deploy, so it cannot be scheduled for a quiet window, rehearsed against a copy, or aborted after the first few rows look wrong.
It gives no way to see what would change before anything does.
Describe refactoring alternatives to redesign the code
A command with these properties:
Idempotent, so resuming is just running it again: rows whose name already matches sounds/<uuid>.<ext> are skipped.
Safe ordering — write the new object, update the row, then delete the old object. Interrupted at any point, the worst outcome is an orphaned old file, never a row pointing at nothing.
--dry-run to list what would change without touching storage.
--limit N so a first batch can be small and inspected.
Per-row error isolation: a failure is logged with the key and the run continues, rather than aborting and leaving the job half-done with no record of where.
Activity