readAccounts (src/ipc/accountStore.ts) caches an empty map whenever the store file cannot be decrypted or parsed, and the next saveAccountSecrets writes that empty map back over the file through writeAccounts. That is a deliberate choice, not an oversight; the comment above writeAccounts explains it: refusing to write over an undecryptable file would leave the launcher permanently unable to save any account.
At single-account scale this cost the one account the old store held. Since multi-account (#238), the same behavior costs every saved account's session in one shot: one player logging in again after an undecryptable store event wipes the sessions of every other account on the same device, not just their own.
Raised during review of PR #253 (#253 (review)): "An undecryptable store now costs every saved account its session rather than the one the old store held. readAccounts caches an empty map on any failure and the next saveAccountSecrets writes that map back over the file. Your comment in writeAccounts says exactly this and I think the call is right given the backup, but it is worth a follow-up issue rather than only a comment, because the blast radius genuinely grew."
Not fixed in #253; distinguishing "no file" from "present but undecryptable" would need a real decision about writeAccounts' refusal policy (letting a re-login for one account fail outright when a housemate's store is unreadable is its own UX question), not a one-line change bundled into that PR.
Worth exploring: a real fix likely needs readAccounts to distinguish "file absent" from "file present but corrupt" and let saveAccountSecrets refuse (or warn) rather than silently overwrite in the corrupt case, while still allowing a first-ever save to proceed normally.
readAccounts(src/ipc/accountStore.ts) caches an empty map whenever the store file cannot be decrypted or parsed, and the nextsaveAccountSecretswrites that empty map back over the file throughwriteAccounts. That is a deliberate choice, not an oversight; the comment abovewriteAccountsexplains it: refusing to write over an undecryptable file would leave the launcher permanently unable to save any account.At single-account scale this cost the one account the old store held. Since multi-account (#238), the same behavior costs every saved account's session in one shot: one player logging in again after an undecryptable store event wipes the sessions of every other account on the same device, not just their own.
Raised during review of PR #253 (#253 (review)): "An undecryptable store now costs every saved account its session rather than the one the old store held.
readAccountscaches an empty map on any failure and the nextsaveAccountSecretswrites that map back over the file. Your comment inwriteAccountssays exactly this and I think the call is right given the backup, but it is worth a follow-up issue rather than only a comment, because the blast radius genuinely grew."Not fixed in #253; distinguishing "no file" from "present but undecryptable" would need a real decision about
writeAccounts' refusal policy (letting a re-login for one account fail outright when a housemate's store is unreadable is its own UX question), not a one-line change bundled into that PR.Worth exploring: a real fix likely needs
readAccountsto distinguish "file absent" from "file present but corrupt" and letsaveAccountSecretsrefuse (or warn) rather than silently overwrite in the corrupt case, while still allowing a first-ever save to proceed normally.