fix: clean up corrupt partial downloads to prevent infinite extraction loop by sheeki03 · Pull Request #1015 · cjpais/Handy

sheeki03 · 2026-03-12T11:53:18Z

Before Submitting This PR

Please confirm you have done the following:

I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate
I have read CONTRIBUTING.md

Human Written Description

When a directory-based model download completes but extraction fails (e.g. corrupt archive, interrupted extraction), the .partial tar.gz file is left behind. On the next download attempt the app resumes from EOF, thinks the download is complete, and retries extraction on the same broken archive — stuck in an infinite loop with no way to re-download.

This fix ensures the corrupt .partial is deleted when extraction fails so the next attempt starts a fresh download. It also distinguishes between archive corruption (delete .partial) and environmental failures like permissions or disk space (preserve .partial since the archive itself may be valid). The frontend is also fixed to clear stale download/progress state when extraction fails.

Related Issues/Discussions

Fixes #858

The maintainer suggested: "checksum and if the checksum does not match, delete the file and re-download." This PR addresses the core stuck-download loop without checksums (no canonical hash source is available). Checksum validation can be added as a follow-up if model hashes are published.

Community Feedback

Issue #858 has 2 comments including the maintainer confirming the bug and suggesting the fix direction.

Testing

Automated:

1 new unit test (test_extraction_failure_cleans_up_partial_file) verifying that a corrupt .partial is deleted after extraction failure and the .extracting directory is cleaned up
All 4 model manager tests pass: cargo test --lib managers::model::tests

Manual (macOS, M4 MacBook Air, dev build via bun tauri dev):

Corrupt archive cleanup (core bug):
- Deleted extracted Moonshine V2 Tiny model directory
- Created a 31MB corrupt .partial file (random bytes, not a valid tar.gz)
- Restarted app, model showed as not downloaded
- Clicked Download, app resumed from EOF, attempted extraction, extraction failed
- .partial was deleted, backend state reset, UI cleared
- Clicked Download again, fresh download started from scratch, completed successfully
Resume regression (must not break):
- Started downloading Moonshine V2 Tiny, cancelled mid-download at ~20MB
- Restarted app, .partial preserved at 20MB
- Clicked Download, resumed from byte 20159808 (not from 0%), completed successfully

Backend log evidence:

[INFO] Resuming download of model moonshine-tiny-streaming-en from byte 32505856
[INFO] Extracting archive for directory-based model: moonshine-tiny-streaming-en
[INFO] Starting fresh download of model moonshine-tiny-streaming-en
[INFO] Successfully extracted archive for model: moonshine-tiny-streaming-en

Screenshots/Videos (if applicable)

N/A — download/extraction behavior, not UI changes.

AI Assistance

AI was used (please describe below)

If AI was used:

Tools used: Claude Code
How extensively: Claude Code helped with implementation, code review, and test writing. The fix approach (scoped file handles for Windows compat, separate cleanup paths for corrupt archives vs environmental failures) and manual testing were done collaboratively.

…n loop When extraction of a directory-based model fails (corrupt archive), the .partial file was left in place and download state was not reset. This caused the next download attempt to resume from EOF, "complete" instantly, and retry extraction on the same broken archive — looping forever. This fix: - Scopes archive file handles so they are dropped before cleanup (Windows compat) - Deletes .partial on extraction failure (corrupt archive) but preserves it on setup failures (permissions, disk space) since the archive may be valid - Resets all backend state (is_downloading, partial_size, cancel flags) - Clears frontend download state maps on extraction failure to prevent stuck UI

cjpais · 2026-03-12T12:44:56Z

I'm not convinced this is the way forward. If you as a human want to review the code and tell me I'm wrong let me know.

I can easily (trivially) compute the hashes. This to me seems like a band-aid solution which just adds more code and possibility for faults. The code is already a giant mess in this department, and I think it's almost better to just fundamentally rethink all of it, or rip it out.

sheeki03 · 2026-03-12T12:53:08Z

Gotcha...I avoided checksums, but I can just download the files from blob.handy.computer and compute them myself.
That would catch corruption before extraction even starts, which is simpler overall

cjpais · 2026-03-12T13:53:50Z

Yeah right now I think maybe going the simpler way might be best.

Certainly there's a way to handle partial downloads, I'm just a bit wondering how much it matters to handle this. More or less I think it would mean revisiting this code overall and seeing if there's a simpler solution. It seems like things are kind of just in a busted state and I would rather make a proper fix, or move to checksums.

Most of the models are a few hundred MB and not multi gig files

VirenMohindra

the fix is directionally correct — deleting .partial on extraction failure is the right call. left a few notes inline.

VirenMohindra · 2026-03-16T03:02:39Z

src-tauri/src/managers/model.rs

+                let _ = self.app_handle.emit(
+                    "model-extraction-failed",
+                    &serde_json::json!({
+                        "model_id": model_id,


this cleanup block (unlock extracting, unlock models, unlock cancel_flags, emit event, return error) is repeated 3 times in this PR — here, in the create_dir_all failure path, and in the File::open failure path. that's ~25 lines × 3. a helper like fn fail_extraction(&self, model_id: &str, error_msg: &str, delete_partial: bool) would cut this to ~10 lines total and make the intent clearer.

VirenMohindra · 2026-03-16T03:02:39Z

src-tauri/src/managers/model.rs

+                    if let Some(model) = models.get_mut(model_id) {
+                        model.is_downloading = false;
+                        model.partial_size = 0;
+                    }


this is the actual one-line fix for #858 — nice. on current main, this line is missing and the .partial file survives extraction failure, causing the infinite loop. everything else in the PR is hardening around this.

VirenMohindra · 2026-03-16T03:02:39Z

src-tauri/src/managers/model.rs

+                    Ok(f) => f,
+                    Err(e) => {
+                        // File::open failure is environmental, preserve .partial
+                        let error_msg = format!("Failed to open archive: {e}");


good catch scoping the file handles for windows compat. worth keeping even in a slimmer version of this PR.

VirenMohindra · 2026-03-16T03:02:39Z

src-tauri/src/managers/model.rs

+                        {
+                            let mut extracting = self.extracting_models.lock().unwrap();
+                            extracting.remove(model_id);
+                        }


File::open failing on a .partial that we know exists is unusual — likely permissions or the file was deleted between the existence check and the open. preserving .partial here is fine but this is a very rare edge case. might not be worth 25 lines of dedicated handling vs just falling through to the same "delete and retry" path.

cjpais · 2026-03-18T12:42:50Z

also @tanshkoul if you want to help out, testing this pr, or helping to improve/review/etc would be very helpful

cjpais · 2026-03-19T08:01:04Z

closing in favor of #1095

sheeki03 added 2 commits March 12, 2026 17:22

fix: inline format args to satisfy clippy

b1cc999

VirenMohindra reviewed Mar 16, 2026

View reviewed changes

VirenMohindra mentioned this pull request Mar 16, 2026

[BUG] Partial downloads prevent the model from ever being downloaded again #858

Closed

VirenMohindra mentioned this pull request Mar 19, 2026

fix: sha256 verification to prevent corrupt partial download loop #1095

Merged

3 tasks

cjpais closed this Mar 19, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: clean up corrupt partial downloads to prevent infinite extraction loop#1015

fix: clean up corrupt partial downloads to prevent infinite extraction loop#1015
sheeki03 wants to merge 2 commits intocjpais:mainfrom
sheeki03:fix/partial-download-cleanup

sheeki03 commented Mar 12, 2026

Uh oh!

cjpais commented Mar 12, 2026

Uh oh!

sheeki03 commented Mar 12, 2026

Uh oh!

cjpais commented Mar 12, 2026 •

edited

Loading

Uh oh!

VirenMohindra left a comment

Uh oh!

VirenMohindra Mar 16, 2026

Uh oh!

VirenMohindra Mar 16, 2026

Uh oh!

VirenMohindra Mar 16, 2026

Uh oh!

VirenMohindra Mar 16, 2026

Uh oh!

cjpais commented Mar 18, 2026

Uh oh!

cjpais commented Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

sheeki03 commented Mar 12, 2026

Before Submitting This PR

Human Written Description

Related Issues/Discussions

Community Feedback

Testing

Screenshots/Videos (if applicable)

AI Assistance

Uh oh!

cjpais commented Mar 12, 2026

Uh oh!

sheeki03 commented Mar 12, 2026

Uh oh!

cjpais commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VirenMohindra left a comment

Choose a reason for hiding this comment

Uh oh!

VirenMohindra Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

VirenMohindra Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

VirenMohindra Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

VirenMohindra Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

cjpais commented Mar 18, 2026

Uh oh!

cjpais commented Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cjpais commented Mar 12, 2026 •

edited

Loading