clawbot
5c4a671d4a
Both methods answered from currentNetwork(), which reads the module-level state singleton, and nothing populates that at module scope. A service worker revived by the page's own message therefore held DEFAULT_STATE and reported mainnet 0x1 / 1 to a page whose user was on Sepolia, so a dApp asking which chain the wallet is on built its interaction for the wrong one. Neither method is gated on a connection, so any page got the stale answer. Both now answer from getState() — the per-call storage read that returns a detached object, which every other read handler in this file already uses — rather than by loading the singleton. Loading it would fix the stale answer but introduce a worse defect on the same path: loadState() replaces state.wallets wholesale, and backgroundRefresh() hands the singleton's wallets to refreshBalances(), which mutates those address objects in place across a network round trip before stamping lastBalanceRefresh and saving. A load landing inside that round trip detaches the objects being mutated, so the save persists the pre-refresh balances while still marking the refresh done, and the freshness guard then suppresses the redo for half the alarm period. These two methods are reachable by any page, and the injected provider sends eth_chainId on every page load, so an ordinary page load would be enough to drop a refresh and a polling page could keep any refresh from ever persisting. getState() reads storage once per call and mutates nothing shared. networkById(undefined) already falls back to mainnet, which is the answer a profile with no stored networkId had before. Read-side audit of the background, which the fix was the occasion for: the other singleton reads are wallet_switchEthereumChain, the transaction verify/broadcast path and backgroundRefresh, and all three already load first. Every other handler answers from storage per call through getState(). One stale read remains and is deliberately not fixed here, being a different handler rather than the same one-line shape: handleSendTransaction calls getProvider() with no network name, so balances.js falls back to the same unloaded singleton for ethers' static network hint, and a cold-worker send on Sepolia is prepared with a mainnet hint. It is caught later — the artifact is verified against the loaded chain before broadcast — so it fails the send rather than sending on the wrong chain. The test's storage stub structured-clones in both directions, as the real chrome.storage.local does. A stub that hands back the live stored object aliases it into whatever reads it, which makes an in-place mutation of a detached copy look as though it reached storage and hides this entire class of defect: with an aliasing get, the whole suite passes against the loadState() version above. Verified failing first, two mutations, each with the rest of the tree untouched. Reverting the handler to the singleton read gives 3 failed / 791 passed: exactly the three cases that read the chain on a cold worker, each answering 0x1 / 1 instead of 0xaa36a7 / 11155111. Replacing getState() with await loadState() plus currentNetwork() gives 1 failed / 793 passed: the new mid-refresh case, with the persisted balance "0" where the refresh wrote "1.5". With the fix, 794 passed / 37 suites, and lint ran uncached in the pinned container.
8.7 KiB
8.7 KiB