Skip to content

fix: Saved Connections Lost #1041

Open
ohansyah wants to merge 1 commit into
antares-sql:masterfrom
ohansyah:ISSUE-913#All_Saved_Connections_lost_when_opening_a_second_window
Open

fix: Saved Connections Lost #1041
ohansyah wants to merge 1 commit into
antares-sql:masterfrom
ohansyah:ISSUE-913#All_Saved_Connections_lost_when_opening_a_second_window

Conversation

@ohansyah

@ohansyah ohansyah commented Jul 3, 2026

Copy link
Copy Markdown

Issue #913 All Saved Connections lost when opening a second window

Root cause
The connections store uses electron-store with encryption to protect passwords. The encryption key was managed through safeStorage (Electron's OS keychain API). On Flatpak/Linux where safeStorage is unavailable, the key couldn't be persisted:

  • set-key handler silently dropped the key when safeStorage was unavailable
  • get-key returned false when safeStorage was unavailable
  • A second window or app restart would generate a different encryption key
  • clearInvalidConfig: true on the store would then silently delete the encrypted file when decryption failed with the wrong key permanent data loss

Changes made
src/main/ipc-handlers/application.ts (main process key persistence):

  • set-key: Always persists the key now. If safeStorage is available, encrypts it; otherwise stores the key as plain text in the session store (same directory, same file-system protection).
  • get-key: Always reads from the store. Tries safeStorage decryption first, falls back to raw key read if unavailable or decryption fails.

src/renderer/stores/connections.ts (renderer key retrieval + data safety):

  • Refactored key retrieval into getEncryptionKey() always uses the main process as the source of truth, with localStorage as a fast cache.
  • Wrapped store creation in createPersistentStore() if the store file can't be decrypted (e.g., real corruption), it backs up the file with a .corrupt extension before resetting, rather than silently deleting it.

Result

  • Second windows and app restarts now always get the same encryption key
  • clearInvalidConfig: true can no longer trigger on key mismatch only on genuine file corruption
  • In the worst case, a backup file is preserved for manual recovery

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