Reported as "opening Aegis makes Theseus get stuck / not responding", and it
was Aegis's fault.
The host's add-on store is ONE JSON file per add-on, and storage.get() does a
readFileSync plus a JSON.parse of the whole thing on every call —
synchronously, on the Electron main thread, the thread that drives the entire
browser. storage.set() additionally stringifies and writes all of it.
That store had grown to 7.4 MB, 99.9% of it one wallet's txCache: getTx()
kept every transaction it ever fetched, with full vin/vout arrays, and a busy
chipnet test wallet had thousands. Measured on the real file: parse 59 ms,
stringify 39 ms. So one storage.get blocked the UI for ~60 ms, one set for
~99 ms, and fullState() — which reads the store seven times over
selectedWalletId, walletRoles, walletEntries, snapshotForSelected and the
server list — cost ~420 ms. emitState() runs on every adapter change, across
nine wallets, so the main thread was never given back.
Three changes:
- txCache is capped at 400 entries, pruned newest-first by block time
(unconfirmed entries sort as newest — they are the current ones). Worst
case ~0.3 MB per wallet instead of unbounded.
- TX_CACHE_VERSION 3, so existing oversized caches are discarded on first
load rather than needing a manual clear.
- loadHistory() only persists when something actually changed; an idle wallet
was rewriting the whole file on every poll for nothing.
- api.storage gains a write-through read cache, so repeated gets cost one
parse per process instead of one per call. Writes still go to the host
unchanged. Safe because this process is the only writer — Aegis's panel
talks over addon messages and never touches addon storage; if that changes,
the cache has to go.
40683c84cf