Skip to content

fix(compress): compressing works in a real library, and says how it went - #59

Merged
DarrellVS merged 1 commit into
devfrom
compress-feedback
Sep 23, 2026
Merged

DarrellVS merged 1 commit into
devfrom
compress-feedback

Conversation

@DarrellVS

Copy link
Copy Markdown
Owner

Compressing a clip failed in a real library: rows store forward-slash paths and shell.trashItem rejects them ("Failed to parse path"). Compression now goes through MoveFileToTrashAction, which normalises the path, the same as delete.

  • A toast now reports the outcome: "60.6 MB to 19.2 MB", left alone and why, or failed and why. The card updates at once. Batch compress reports each clip.
  • The compress bench shell stub now refuses forward slashes like Windows does, and the bench can take a file path. Proved: it fails without the fix and passes with it (real clip 60.6 to 19.2 MB).
  • The clip name is bold in the confirm dialog (new emphasis option).
  • The scan now retires a duplicate row for the same file (from an older build), but only when that row holds nothing of its own. Rows only, never files. Unit tested; verified in the test profile.

Gates: npm run check 866; compress-check exit 0; indexing, compress and modals specs 12 passed.

🤖 Generated with Claude Code

**Compression failed on every clip in a real library, after the encode.**
Rows store paths with forward slashes, the way fast-glob returns them, and
`CompressClipAction` handed that straight to `shell.trashItem`, which on
Windows refuses it with "Failed to parse path". `MoveFileToTrashAction`
already normalises for exactly this; compression now goes through it.
Checked in Electron: a forward-slash path fails, a normalised one lands in
the Recycle Bin. 232 of the 233 clips in the real library store their path
that way.

**It was silent about it.** The menu said "It will finish in the
background" and nothing more, so a compressed clip, one left alone for
being already small, and one that failed all looked the same, with the
card's old size. `useCompressionResult` now follows the job: the card gets
the new row the moment it lands, and one toast says "60.6 MB to 19.2 MB",
why it was left alone, or why it failed. Batch compression reports each.

**The bench could not have caught it**, because its shell stub deleted any
path it was given. It now refuses a forward slash the way Windows does and
stores the row's path the way a real library does, and it takes a file:
`node scripts/compress-check.mjs <file>`. Proved: without the fix it fails
with "Failed to parse path"; with it, the real clip goes 60.6 to 19.2 MB.

**The clip's name is bold in the question**, through a new `emphasis`
option on the confirm dialog (plain text either side, never HTML).

**A duplicate row found on the way.** `Edited_2026-09-19` had two rows,
one per slash spelling, from a build older than the scan's path matching.
The scan never removed the old one because the file exists. It now retires
a second row for a file when that row holds nothing its twin lacks
(`services/duplicateRows.ts`, unit-tested): rows only, never the file, and
a duplicate carrying anything of its own is left and logged. In the test
profile it removed the empty twin and kept the published row.

Gates: `npm run check` 866; `compress-check.mjs` on the real clip, exit 0;
`indexing`, `compress` and `modals` specs, 12 passed.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@DarrellVS DarrellVS added this to the 3.5.0 milestone Sep 23, 2026
@DarrellVS DarrellVS added the bug Something isn't working label Sep 23, 2026
@DarrellVS DarrellVS self-assigned this Sep 23, 2026
@DarrellVS
DarrellVS merged commit 6bf949f into dev Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant