Symptom
When hub returns a different vault URL on a reconnect token vs the original (e.g. `localhost:1940` first time, `hub.example/vault/default` after attaching a custom domain), `vaultIdFromUrl` produces a different slug → `addVault` creates a new vault record while the original record stays in the store. Repeat over multiple drift cycles → multiple orphan records.
Repro
- Add vault at one URL → vault record A
- Reconnect through hub that returns a different URL → vault record B added, banner cleared on both (fix from notes#148)
- Record A remains in the store but isn't actively used
Why notes#148 didn't fix this
notes#148 fixed the BANNER-persistence symptom (priorHaltedVaultId clears both halts). The underlying vault-record duplication remains.
Possible fixes
- A: detect URL-drift on OAuth callback and migrate the OLD vault record's data/state to the new id (single record, just rename)
- B: leave duplicates but add a "cleanup orphaned vaults" admin action in settings
- C: on reconnect, prefer reusing the prior vault's id (treat the new URL as a "moved" record, not a new one)
Severity
Low for v0.6 — drift cycles are rare. Could bite operators who change their hub URL multiple times.
Filed from notes#148 reviewer flag.
Symptom
When hub returns a different vault URL on a reconnect token vs the original (e.g. `localhost:1940` first time, `hub.example/vault/default` after attaching a custom domain), `vaultIdFromUrl` produces a different slug → `addVault` creates a new vault record while the original record stays in the store. Repeat over multiple drift cycles → multiple orphan records.
Repro
Why notes#148 didn't fix this
notes#148 fixed the BANNER-persistence symptom (priorHaltedVaultId clears both halts). The underlying vault-record duplication remains.
Possible fixes
Severity
Low for v0.6 — drift cycles are rare. Could bite operators who change their hub URL multiple times.
Filed from notes#148 reviewer flag.