fix: persist empty connection state after disconnect

[fuleinist]

Summary

• Track whether connections have ever been opened using a ref
• Persist all connection state changes (including empty states) after first connection
• Prevents stale connection data from being restored on app restart

Root cause

The persistence effect was skipping when openConnectionIds was empty, which meant disconnected connections weren't being cleared from backend storage. This caused the app to reopen connections on next launch even after the user had manually closed them.

Fix

Added a ref to track whether connections have ever been opened during the session. Once true, the persistence effect runs for all state changes including empty ones. This preserves the original intent (not wiping state during startup before auto-connect) while ensuring user-initiated disconnects are properly persisted.

Closes #548

[debba]

Hey @fuleinist, thanks for digging into #548! I took this for a spin locally and found a few things worth discussing before merging.

First thing: the new test also passes without the fix 😅 I ran it against main's version of DatabaseProvider.tsx and it's still green (21/21). Turns out disconnect() already persists the empty list explicitly, that was added in #467 (see the comment block around DatabaseProvider.tsx:857-862) and it shipped in v0.17.0. So user-initiated disconnects were already covered.

Which means the bug in #548 comes from somewhere else. I think I found it: SettingsProvider is resurrecting the stale list. The chain is:

1. On mount it loads the full config (get_config returns the whole AppConfig in camelCase, lastOpenConnectionIds included) and spreads it into the settings state.
2. Every updateSetting() sends the entire settings object back to save_config.
3. The Rust merge (config.rs:458) sees Some(<the list from app startup>) and happily overwrites the [] that disconnect() just wrote.

Repro: open a connection, close it, change any setting (font size, whatever), quit, relaunch. It reconnects. You can watch it happen with jq '.lastOpenConnectionIds' ~/.config/tabularis/config.json between steps. This PR doesn't touch that path, so #548 would still reproduce.

There's also a regression risk with the current approach: once hasEverHadConnectionsRef flips true, the effect persists [] for any empty state, including the health-check cleanup path (connection-health-failed). So if your DB blips while the app is running, your saved session gets wiped and nothing restores on next launch. Same story for detachConnection when moving your only connection to a new window: the main window persists [] while the connection is still open elsewhere. #467 deliberately kept the persist tied to explicit user actions to avoid exactly this.

So my suggestion would be to fix this in SettingsProvider instead: strip the session fields (lastOpenConnectionIds, lastActiveConnectionId) before calling save_config, so settings saves can't clobber what the session-persistence code wrote. That fixes #548 without touching the effect guard at all.

Happy to help test if you want to rework it in that direction!

[fuleinist]

Thanks for the thorough review @debba — you're absolutely right on all counts.

I've reworked the fix following your suggestion. Instead of adding the ref guard in DatabaseProvider, I'm now stripping the session fields (lastOpenConnectionIds, lastActiveConnectionId) before save_config in SettingsProvider.

Changes:

• Added stripSessionFields helper in src/utils/settings.ts
• Updated SettingsProvider.updateSetting() and the localStorage migration path to strip session fields before persisting
• Reverted the hasEverHadConnectionsRef guard in DatabaseProvider (kept the original simple if (length === 0) return guard that fix: don't restore tabs of a disconnected connection on next launch #467 added)
• Added tests for the new helper

This fixes #548 at the root cause: settings saves can no longer clobber session state, and DatabaseProvider remains the single source of truth for session persistence.

The existing DatabaseProvider test that verifies disconnect() explicitly persists the empty list still passes — that explicit persist is still needed for the case where the user disconnects the last connection (the reactive effect skips the empty list, so we persist directly from the user action).

All tests pass (3488/3488), typecheck and lint clean.

Pushed as 02c21da.

[debba]

Thanks @fuleinist for digging into this one and finding the real culprit. The stale session list getting written back on every settings save was sneaky, and stripping the session fields at the source is the right call. Ran the full suite locally and verified the repro from #548 is gone. Merging!