Skip to content

Add safe manual compression stop choices - #5

Merged
marcmy merged 39 commits into
masterfrom
agent/compression-stop-options
Jul 22, 2026
Merged

marcmy merged 39 commits into
masterfrom
agent/compression-stop-options

Conversation

@marcmy

@marcmy marcmy commented Jul 21, 2026 •

Copy link
Copy Markdown
Owner

Summary

Replace the manual-compression red X with an explicit three-way stop decision:

  • Save progress keeps files already compressed, persists the selected compression mode and skip/watch settings, and offers to resume when the folder is added again.
  • Undo progress restores only files successfully changed during the current run to each file's previous compression state.
  • Leave as is keeps the partially compressed folder without creating a saved resume session; adding it later behaves like a normal fresh add.

Previous behavior

The red X directly cancelled the active compressor and the surrounding workflow then performed an unconditional full folder analysis and state refresh. There was no user choice, no persisted resume intent, and no precise record of which files had been changed during that run.

Implementation

  • pause compression while the stop dialog is open
  • record every successfully changed file together with its original WOF compression mode
  • use that run ledger for targeted rollback rather than decompressing the entire folder
  • persist resumable sessions in compression-resume.json under CompactGUI's existing data directory
  • restore the saved target algorithm, skip-list settings, and watcher preference when resuming
  • prompt on re-add with Resume, Discard saved progress, or Cancel
  • let the compressor naturally skip files already using the saved target, so resumed work continues with the remaining files
  • add an Undoing compression UI state while targeted restoration is running
  • preserve the watcher compression target appropriately for completed, saved, undone, and leave-as-is outcomes
  • keep ordinary manual decompression cancellation separate from this compression-only dialog

Already-compressed folder regression

A folder already fully using the selected algorithm produced an empty eligible-file list. The compressor incorrectly returned this as a successful fresh compression, sending the UI through success-only completion handling after the progress bar jumped immediately to 100%.

The empty-work path now reports 100% but returns no compression occurred. This suppresses the fresh-compression notification/state path and preserves the folder's existing compression and watcher target. Progress calculation also defensively handles a zero-byte denominator.

Validation

  • Windows x64 restore and self-contained publish pass with TreatWarningsAsErrors=true
  • packaging and artifact upload pass
  • supply-chain audit passes
  • final PR diff contains only the 15 feature files; no temporary diagnostic or workflow changes remain

Runtime test plan

  1. Start manual compression on a folder large enough to stop mid-run.
  2. Click the red X and verify compression pauses while the three choices are shown.
  3. Choose Save progress, remove the folder, add it again, and verify the resume prompt restores the saved algorithm and options before continuing.
  4. Repeat and choose Leave as is; verify no resume prompt appears when the folder is added again and its partial compression remains untouched.
  5. Repeat and choose Undo progress; verify only files changed during that run are restored, including files that previously used another WOF mode.
  6. Verify pause/resume still works normally and the red X for a manual decompression run remains a direct cancel.
  7. For a watched folder, verify completed or saved progress preserves the selected compression target while undo/leave-as-is preserves its previous watcher target.
  8. Add a folder already fully compressed with the selected algorithm, click Compress Again, and verify the progress bar reaches 100% without a crash or fresh-compression notification.

marcmy commented Jul 22, 2026

Copy link
Copy Markdown
Owner Author

Follow-up after runtime retest: the first zero-work patch was incomplete. It changed the compressor return value, but HomeViewModel still unconditionally reanalysed the folder, called UpdateWatched, and revisited the folder in the later watcher synchronization loop.

The corrected implementation now propagates the compressor's actual eligible-file count as CompressionRunResult.HadWork. When HadWork is false, the manual run exits before re-analysis, notification, watcher update, or existing-watcher replacement. Existing watched folders with no compression work are also skipped by the later batch synchronization loop.

Validated on final head 421bf1f44c93de86441af0b6bf33d77b03111733: strict Windows x64 publish, packaging, artifact upload, and supply-chain audit all pass. Runtime regression test remains: fully LZX folder -> Compress Again -> LZX -> Compress Selected.

@marcmy
marcmy marked this pull request as ready for review July 22, 2026 06:59
@marcmy
marcmy merged commit 1506fed into master Jul 22, 2026
8 checks passed
@marcmy
marcmy deleted the agent/compression-stop-options branch July 22, 2026 06:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant