loadState() in src/shared/state.js takes hasWallet straight from storage and never checks it against wallets.length.
Consequence: any profile already saved in an inconsistent state stays broken after the fix in #156 — the extension keeps believing a wallet exists, and only a subsequent add or delete repairs it. That is every user who deleted their last wallet on a build predating that fix. The fix there corrects the write path; this is the read path.
Found while implementing #156 and deliberately left out of its scope.
Implementation requirements
loadState() must derive hasWallet from wallets.length rather than trusting the persisted value, or reconcile and persist the correction on load.
Decide and state which: silently deriving is simplest, but if any code depends on hasWallet differing from wallets.length legitimately, that must be established first rather than assumed.
Do not widen this into a general state-migration framework.
Definition of done
A stored state with hasWallet: true and zero wallets loads as having no wallet, and the popup lands on the welcome screen.
A stored state with hasWallet: false and one or more wallets loads as having a wallet.
Unit tests cover both directions of the inconsistency, and are demonstrated failing against the current code.
TODO.md updated in the same commit.
make check passes.
`loadState()` in `src/shared/state.js` takes `hasWallet` straight from storage and never checks it against `wallets.length`.
Consequence: any profile already saved in an inconsistent state stays broken after the fix in https://git.eeqj.de/sneak/AutistMask/issues/156 — the extension keeps believing a wallet exists, and only a subsequent add or delete repairs it. That is every user who deleted their last wallet on a build predating that fix. The fix there corrects the write path; this is the read path.
Found while implementing https://git.eeqj.de/sneak/AutistMask/issues/156 and deliberately left out of its scope.
## Implementation requirements
- `loadState()` must derive `hasWallet` from `wallets.length` rather than trusting the persisted value, or reconcile and persist the correction on load.
- Decide and state which: silently deriving is simplest, but if any code depends on `hasWallet` differing from `wallets.length` legitimately, that must be established first rather than assumed.
- Do not widen this into a general state-migration framework.
## Definition of done
- [ ] A stored state with `hasWallet: true` and zero wallets loads as having no wallet, and the popup lands on the welcome screen.
- [ ] A stored state with `hasWallet: false` and one or more wallets loads as having a wallet.
- [ ] Unit tests cover both directions of the inconsistency, and are demonstrated failing against the current code.
- [ ] `TODO.md` updated in the same commit.
- [ ] `make check` passes.
clawbot
added this to the 1.0.0 milestone 2026-08-11 14:19:15 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
loadState()insrc/shared/state.jstakeshasWalletstraight from storage and never checks it againstwallets.length.Consequence: any profile already saved in an inconsistent state stays broken after the fix in #156 — the extension keeps believing a wallet exists, and only a subsequent add or delete repairs it. That is every user who deleted their last wallet on a build predating that fix. The fix there corrects the write path; this is the read path.
Found while implementing #156 and deliberately left out of its scope.
Implementation requirements
loadState()must derivehasWalletfromwallets.lengthrather than trusting the persisted value, or reconcile and persist the correction on load.hasWalletdiffering fromwallets.lengthlegitimately, that must be established first rather than assumed.Definition of done
hasWallet: trueand zero wallets loads as having no wallet, and the popup lands on the welcome screen.hasWallet: falseand one or more wallets loads as having a wallet.TODO.mdupdated in the same commit.make checkpasses.