[PR #5799] [MERGED] fix(desktop): use store dir for unified store path #5356

Closed
opened 2026-03-17 02:48:47 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/5799
Author: @CuriousCorrelation
Created: 1/23/2026
Status: Merged
Merged: 1/23/2026
Merged by: @jamesgeorge007

Base: nextHead: fix-desktop-redirect-reads-to-correct-store


📝 Commits (1)

  • 843154f fix(desktop): use store dir for unified store path

📊 Changes

1 file changed (+3 additions, -3 deletions)

View changed files

📝 packages/hoppscotch-desktop/src/kernel/store.ts (+3 -3)

📄 Description

The desktop shell was reading from instance/hoppscotch-unified.store
while the webapp writes to store/hoppscotch-unified.store. This caused
the app to lose track of the last connected instance on restart.

Closes FE-1121
Closes #5798

Regression source

PR #5259 (feat(desktop): portable phase-1 foundational) introduced both
hoppscotch-desktop/src/kernel/store.ts and
hoppscotch-selfhost-web/src/kernel/store.ts using getInstanceDir()
consistently, following the FE-937 design where instance/ was intended
for kernel store files containing connection state, recent instances, etc.

PR #5747 (perf(desktop): cache store path resolution) changed
selfhost-web from getInstanceDir() to getStoreDir() but did not
update the desktop shell, introducing the path mismatch:

Desktop shell: {config}/latest/instance/hoppscotch-unified.store
Webapp: {config}/latest/store/hoppscotch-unified.store

When the user switches instances in the webapp, state saves to store/.
On restart, the desktop shell reads from instance/ and finds stale or
default state.

Why this was hard to reproduce

The bug only manifests reliably on fresh installs. On existing machines,
the migration service (CURRENT_STORE_VERSION = 1 in
InstanceStoreMigrationService) has already run and won't run again
since the version check passes.

The migration reads from legacy stores (hopp.store.json,
hoppscotch-desktop.store) and writes to the kernel store. Since the
desktop shell uses instance/ path, migrated data goes there. After
migration completes, the webapp writes to store/ but migration never
reruns, leaving stale data in instance/ that the desktop shell reads
on startup.

On existing machines, working data from before the path divergence was
introduced, or the timing of instance connections relative to migrations,
might mean data happened to be in sync coincidentally.

What's changed

Changed getInstanceDir() to getStoreDir() in the desktop shell's
store path resolution to match #5747's change to selfhost-web:

const getStorePath = async (): Promise<string> => {
  try {
    const instanceDir = await getInstanceDir()
    return join(instanceDir, STORE_PATH)
  } catch (error) {
    console.error("Failed to get instance directory:", error)
    return "hoppscotch-unified.store"
  }
}

to now

const getStorePath = async (): Promise<string> => {
  try {
    const storeDir = await getStoreDir()
    return join(storeDir, STORE_PATH)
  } catch (error) {
    console.error("Failed to get store directory:", error)
    return "hoppscotch-unified.store"
  }
}

No migration needed, no data loss since user data is already in store/.

Follow-up

A subsequent PR will restore the original FE-937 design by moving both
components back to getInstanceDir() with proper migration handling.


Summary by cubic

Point the desktop shell to the unified store directory used by the webapp, so it correctly restores the last connected instance on restart. Fixes FE-1121.

  • Bug Fixes
    • Switched store path resolution from getInstanceDir() to getStoreDir() to read {config}/latest/store/hoppscotch-unified.store.
    • No migration required; data already lives under store/.

Written for commit 843154f9b5. Summary will update on new commits.


🔄 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/5799 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 1/23/2026 **Status:** ✅ Merged **Merged:** 1/23/2026 **Merged by:** [@jamesgeorge007](https://github.com/jamesgeorge007) **Base:** `next` ← **Head:** `fix-desktop-redirect-reads-to-correct-store` --- ### 📝 Commits (1) - [`843154f`](https://github.com/hoppscotch/hoppscotch/commit/843154f9b5f5d2fedbe297b2036ec703a776f143) fix(desktop): use store dir for unified store path ### 📊 Changes **1 file changed** (+3 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-desktop/src/kernel/store.ts` (+3 -3) </details> ### 📄 Description The desktop shell was reading from `instance/hoppscotch-unified.store` while the webapp writes to `store/hoppscotch-unified.store`. This caused the app to lose track of the last connected instance on restart. Closes FE-1121 Closes #5798 ### Regression source PR #5259 (`feat(desktop): portable phase-1 foundational`) introduced both `hoppscotch-desktop/src/kernel/store.ts` and `hoppscotch-selfhost-web/src/kernel/store.ts` using `getInstanceDir()` consistently, following the FE-937 design where `instance/` was intended for kernel store files containing connection state, recent instances, etc. PR #5747 (`perf(desktop): cache store path resolution`) changed selfhost-web from `getInstanceDir()` to `getStoreDir()` but did not update the desktop shell, introducing the path mismatch: Desktop shell: `{config}/latest/instance/hoppscotch-unified.store` Webapp: `{config}/latest/store/hoppscotch-unified.store` When the user switches instances in the webapp, state saves to `store/`. On restart, the desktop shell reads from `instance/` and finds stale or default state. ### Why this was hard to reproduce The bug only manifests reliably on fresh installs. On existing machines, the migration service (`CURRENT_STORE_VERSION = 1` in `InstanceStoreMigrationService`) has already run and won't run again since the version check passes. The migration reads from legacy stores (`hopp.store.json`, `hoppscotch-desktop.store`) and writes to the kernel store. Since the desktop shell uses `instance/` path, migrated data goes there. After migration completes, the webapp writes to `store/` but migration never reruns, leaving stale data in `instance/` that the desktop shell reads on startup. On existing machines, working data from before the path divergence was introduced, or the timing of instance connections relative to migrations, might mean data happened to be in sync coincidentally. ### What's changed Changed `getInstanceDir()` to `getStoreDir()` in the desktop shell's store path resolution to match #5747's change to selfhost-web: ```typescript const getStorePath = async (): Promise<string> => { try { const instanceDir = await getInstanceDir() return join(instanceDir, STORE_PATH) } catch (error) { console.error("Failed to get instance directory:", error) return "hoppscotch-unified.store" } } ``` to now ```typescript const getStorePath = async (): Promise<string> => { try { const storeDir = await getStoreDir() return join(storeDir, STORE_PATH) } catch (error) { console.error("Failed to get store directory:", error) return "hoppscotch-unified.store" } } ``` No migration needed, no data loss since user data is already in `store/`. ### Follow-up A subsequent PR will restore the original FE-937 design by moving both components back to `getInstanceDir()` with proper migration handling. <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Point the desktop shell to the unified store directory used by the webapp, so it correctly restores the last connected instance on restart. Fixes FE-1121. - **Bug Fixes** - Switched store path resolution from getInstanceDir() to getStoreDir() to read {config}/latest/store/hoppscotch-unified.store. - No migration required; data already lives under store/. <sup>Written for commit 843154f9b5f5d2fedbe297b2036ec703a776f143. Summary will update on new commits.</sup> <!-- End of auto-generated description by cubic. --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-03-17 02:48:47 +03:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hoppscotch#5356
No description provided.