fix(updater): download updates through the queue (pause/resume, no crash) - #18
Closed
arousi wants to merge 4 commits into
Closed
fix(updater): download updates through the queue (pause/resume, no crash)#18arousi wants to merge 4 commits into
arousi wants to merge 4 commits into
Conversation
added 4 commits
August 22, 2026 06:16
The old modal UpdateDownloaderDialog streamed the whole release zip while flooding the GUI thread with per-chunk cross-thread progress calls; on a large (205MB) release, concurrent with the live-graph update_ui, it could crash the app mid-download. Route updates through the existing, proven download engine instead: - an available update is added to the normal queue as a DownloadTask (is_update); the user starts it and can pause/resume (Range-resume) it like any other download - update tasks bypass the Cloudflare/CAPTCHA direct-link step and are never auto-extracted - on completion the app offers Install now (restart) or Install on next open; a deferred update is applied via _check_pending_update on launch - execute_update -> _apply_downloaded_update(zip_path): the robust extract -> robocopy swap -> marker-verify -> rollback flow is unchanged, it just consumes the already-downloaded zip Removes the crash-prone modal download path entirely.
Root cause of the 'added but never progresses / connection timed out': the queued update task ran through download_worker on a manager-spawned thread and reused the shared curl_cffi self.dl_session. That session (built on the main thread) hangs with curl (28) for a plain request that never went through the nodriver/get_direct_link path first — normal downloads work only because get_direct_link runs before the transfer. Route update tasks through a dedicated _download_update_file() using urllib (stdlib): supports Range-resume, pause/cancel, progress, and a 416 already-complete short-circuit. Confirmed progressing via the real manager path where curl deterministically hung. Also stop a previously failed update task from blocking a fresh re-offer.
Update downloads were written to a hidden ~/.silverspoon_updates folder, so users couldn't find the completed file. Download to the same Save-To directory as every other download (…/SilverSpoon Update <version>/), so it's visible, consistent, and persists for an install-on-next-open.
Guard the completion prompt and the re-offer dedup on os.path.exists(filepath) so a stale Completed update task (file deleted/moved) neither fires a phantom install prompt nor blocks re-downloading.
This was referenced Aug 22, 2026
Contributor
Author
|
cmon guys, we got work todo. next feature should be throttling download like any other idm, number of concurrent, max speed total, max speed per file, etc. |
arousi
pushed a commit
to arousi/SilverSpoon
that referenced
this pull request
Sep 8, 2026
…, status-pill, ci-build Supersedes the earlier drafts on dev with the rebased PR branches (billysams21#18-billysams21#22 on upstream), merged on top of v1.5.1. Tree is identical to main + the stack.
Contributor
Author
|
Superseded by #27, which carries this change together with the other four fixes on top of v1.5.1 as a single PR from my fork's main. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reworks the auto-updater so a new version downloads through the normal download queue instead of a separate modal downloader.
Problem
The old
UpdateDownloaderDialogstreamed the whole release zip in a modal loop while firing per-chunk cross-thread progress updates. On a large release (~205 MB), concurrent with the live-speed-graphupdate_ui, it could crash the app mid-download.Change
DownloadTask(is_update). The user starts it like any download and can pause/resume it (Range-resume). It downloads to the visible Save-To folder.execute_update→_apply_downloaded_update(zip_path): the robust extract → robocopy dir-swap → marker-verify → rollback flow is unchanged; it just consumes the already-downloaded zip. The crash-prone modal downloader is removed.Backward compatibility
Additive.
DownloadTaskgainsis_update/update_version(persisted). No new dependencies.Verified
Offscreen smoke: update task queues, persists, completes → install prompt, and pending-on-next-open. Scheduler/button unit suites still green. (GUI+network paths are integration-tested via smoke, not unit tests.)