[PR #5126] [MERGED] fix(desktop): in-memory update progress polling #5067

New issue

Closed

opened 2026-03-17 02:33:00 +03:00 by kerem · 0 comments

kerem commented

2026-03-17 02:33:00 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/5126
Author: @CuriousCorrelation
Created: 6/4/2025
Status: ✅ Merged
Merged: 6/13/2025
Merged by: @jamesgeorge007

Base: patch ← Head: fix-desktop-update-progress-polling

📝 Commits (3)

1430e38 fix(desktop): in-memory update progress polling
4839ec4 fix: unused progress tracking in store calls
3208b39 fix: remove progress persistence artifacts

📊 Changes

3 files changed (+66 additions, -36 deletions)

View changed files

📝 packages/hoppscotch-desktop/src/types/index.ts (+0 -4)
📝 packages/hoppscotch-desktop/src/utils/updater.ts (+28 -27)
📝 packages/hoppscotch-desktop/src/views/Home.vue (+38 -5)

📄 Description

This fixes a Windows-specific issue where the updater would hang during download and installation.

The cause was file I/O operations called from within progress callbacks conflicting with Windows' "stricter" fs behavior during concurrent ops.

This move that to an in-memory tracking with periodic polling, removing all disk writes from the download callback to only for actual final commits.

Closes HFE-892
Closes #5038

Notes to reviewers

This is a Windows-specific thing, doesn't affect Mac/Linux functionality.
The core change is moving from synchronous progress persistence to asynchronous polling-based updates.

Progress tracking remains fully functional with 100ms polling intervals for just a bit smooth UI updates.
The existing implementation called saveUpdateState() directly within the updater's progress callback.

This approach worked fine on Mac/Linux but not on Windows apparently due to Windows' mandatory file locking behavior.

According to the docs Windows uses mandatory locking where if one program locks the file, all other programs get error messages when they try to access it, unlike Unix which generally doesn't use locking at all, and when it does, lock is usually advisory.

The Windows file locking behavior stems from its inheritance of "sharing mode" from LAN Manager in the MS-DOS
era, which implements "mandatory locking as a special case" while "Linux doesn't have an equivalent to 'share modes' (all access is allowed by default)".

The updater's internal I/O ops conflicted with progress disk writes because Windows uses whole file locking for most cases, part of the API for opening files CreateFile.

So the fix implements a polling-based arch where progress is stored in memory during download and periodically read by the UI through a polling function.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hoppscotch/hoppscotch/pull/5126 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 6/4/2025 **Status:** ✅ Merged **Merged:** 6/13/2025 **Merged by:** [@jamesgeorge007](https://github.com/jamesgeorge007) **Base:** `patch` ← **Head:** `fix-desktop-update-progress-polling` --- ### 📝 Commits (3) - [`1430e38`](https://github.com/hoppscotch/hoppscotch/commit/1430e3872b17f6aedc5195929fe7e2c430bde8d5) fix(desktop): in-memory update progress polling - [`4839ec4`](https://github.com/hoppscotch/hoppscotch/commit/4839ec496032dd028c4a18d985d630c539cf699b) fix: unused progress tracking in store calls - [`3208b39`](https://github.com/hoppscotch/hoppscotch/commit/3208b39da972962fb0906630c2da750341388675) fix: remove progress persistence artifacts ### 📊 Changes **3 files changed** (+66 additions, -36 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-desktop/src/types/index.ts` (+0 -4) 📝 `packages/hoppscotch-desktop/src/utils/updater.ts` (+28 -27) 📝 `packages/hoppscotch-desktop/src/views/Home.vue` (+38 -5) </details> ### 📄 Description This fixes a Windows-specific issue where the updater would hang during download and installation. The cause was file I/O operations called from within progress callbacks conflicting with Windows' "stricter" fs behavior during concurrent ops. This move that to an in-memory tracking with periodic polling, removing all disk writes from the download callback to only for actual final commits. Closes HFE-892 Closes #5038 ### Notes to reviewers This is a Windows-specific thing, doesn't affect Mac/Linux functionality. The core change is moving from synchronous progress persistence to asynchronous polling-based updates. Progress tracking remains fully functional with 100ms polling intervals for just a bit smooth UI updates. The existing implementation called `saveUpdateState()` directly within the updater's progress callback. This approach worked fine on Mac/Linux but not on Windows apparently due to Windows' mandatory file locking behavior. According to the docs Windows uses mandatory locking where if one program locks the file, all other programs get error messages when they try to access it, unlike Unix which generally doesn't use locking at all, and when it does, lock is usually advisory. The Windows file locking behavior stems from its inheritance of ["sharing mode" from LAN Manager in the MS-DOS era](https://superuser.com/questions/1711476/file-locking-in-windows-linux), which implements "mandatory locking as a special case" while "Linux doesn't have an equivalent to 'share modes' (all access is allowed by default)". The updater's internal I/O ops conflicted with progress disk writes because Windows uses whole file locking for most cases, part of the API for opening files `CreateFile`. So the fix implements a polling-based arch where progress is stored in memory during download and periodically read by the UI through a polling function. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>