Route every removal path through the batch interface #5

New issue

Open

opened 2026-08-25 22:20:10 +02:00 by wokoman · 0 comments

wokoman commented

2026-08-25 22:20:10 +02:00

(Migrated from code.nolog.cz)

What to build

Every way of removing tracks — ironpod rm, ironpod dedupe, and pressing d in the browser — goes through the batch interface from #4, and the single-track primitive becomes private so the guarantee cannot be bypassed.

This is what closes #2. Today the two command-line paths abandon the database write when a deletion fails partway, so tracks vanish from disk while the iPod's database still lists them; the device then shows songs that will not play and cannot be removed. The browser already handled this correctly, by hand. After this ticket there is one implementation and the divergence is gone.

The contract-half of an expand–contract: #4 added the new form beside the old, this removes the old.

Acceptance criteria

ironpod rm and ironpod dedupe write the database even when a deletion fails partway, and report how many were removed before the failure
The browser's delete behaves as it does today — per-item progress, a status line naming the count and the failure — with no visible regression
The single-track removal function is no longer reachable from outside its module
Removing one track is expressed as a batch of one, not as a surviving special case
No call site re-implements "loop, then write once" any more
Verified on a real device: remove a handful of tracks from the browser and from the command line, unplug, and confirm the iPod plays what remains and lists nothing it cannot play
cargo clippy --all-targets clean; full suite passes

Notes

The browser draws its progress popup from inside the removal loop, so its callback captures the terminal while the database is borrowed for the removal. These are disjoint borrows and should compile as-is. If the borrow checker disagrees, raise it rather than redesigning the interface — the callback shape was settled deliberately in #4.

Blocked by

## What to build Every way of removing tracks — `ironpod rm`, `ironpod dedupe`, and pressing `d` in the browser — goes through the batch interface from #4, and the single-track primitive becomes private so the guarantee cannot be bypassed. This is what closes #2. Today the two command-line paths abandon the database write when a deletion fails partway, so tracks vanish from disk while the iPod's database still lists them; the device then shows songs that will not play and cannot be removed. The browser already handled this correctly, by hand. After this ticket there is one implementation and the divergence is gone. The contract-half of an expand–contract: #4 added the new form beside the old, this removes the old. ## Acceptance criteria - [ ] `ironpod rm` and `ironpod dedupe` write the database even when a deletion fails partway, and report how many were removed before the failure - [ ] The browser's delete behaves as it does today — per-item progress, a status line naming the count and the failure — with no visible regression - [ ] The single-track removal function is no longer reachable from outside its module - [ ] Removing one track is expressed as a batch of one, not as a surviving special case - [ ] No call site re-implements "loop, then write once" any more - [ ] Verified on a real device: remove a handful of tracks from the browser and from the command line, unplug, and confirm the iPod plays what remains and lists nothing it cannot play - [ ] `cargo clippy --all-targets` clean; full suite passes ## Notes The browser draws its progress popup from inside the removal loop, so its callback captures the terminal while the database is borrowed for the removal. These are disjoint borrows and should compile as-is. If the borrow checker disagrees, raise it rather than redesigning the interface — the callback shape was settled deliberately in #4. ## Blocked by - #4