Symptom
When the KeepKey Vault desktop app isn't running, the user sees this instead of the intended message:
Cannot use 'in' operator to search for 'data' in KeepKey Vault is not running.
Open the KeepKey Vault desktop app, then try again. Get it at https://keepkey.com/launch
The actual user-facing message — "KeepKey Vault is not running. Open the KeepKey Vault desktop app…" — is correct and actionable. It's just buried inside a TypeError that leads the line, so the user reads a JavaScript error and not the instruction telling them what to do.
Cause
Something along the error path does an 'data' in x membership test where x is a string (the not-running message) rather than the response object it's assumed to be. in throws TypeError on primitives, so the guard meant to inspect a response ends up destroying the message it was handed.
Typical shape:
if ('data' in response) { ... } // response is a string hereFix is a type guard before the membership test:
if (typeof response === 'object' && response !== null && 'data' in response) { ... }What I could not pin down
I could not locate the offending line. Neither the message text nor a matching '<key>' in pattern appears in this repo's .ts/.tsx source or in node_modules on my checkout — and my checkout is behind (pushedAt on the repo is newer than my latest local commit). The only related hit is a bare window.open('https://keepkey.com/launch') at pages/side-panel/src/components/Connect.tsx:60, which is not the source of the composed message.
So this is filed from the observed error string rather than from the code. Whoever picks it up should grep a current tree for the message text and walk back to the caller treating it as an object.
Reproduction
- Quit the KeepKey Vault desktop app entirely
- Trigger any extension action that talks to the vault
- Observe the
TypeError in place of the intended guidance
Why it's worth fixing
"Vault not running" is probably one of the most common states a new user hits, and the one case where the product already knows exactly what to tell them. Right now that instruction is unreadable, which turns a self-service fix into a support ticket.
Symptom
When the KeepKey Vault desktop app isn't running, the user sees this instead of the intended message:
The actual user-facing message — "KeepKey Vault is not running. Open the KeepKey Vault desktop app…" — is correct and actionable. It's just buried inside a
TypeErrorthat leads the line, so the user reads a JavaScript error and not the instruction telling them what to do.Cause
Something along the error path does an
'data' in xmembership test wherexis a string (the not-running message) rather than the response object it's assumed to be.inthrowsTypeErroron primitives, so the guard meant to inspect a response ends up destroying the message it was handed.Typical shape:
Fix is a type guard before the membership test:
What I could not pin down
I could not locate the offending line. Neither the message text nor a matching
'<key>' inpattern appears in this repo's.ts/.tsxsource or innode_moduleson my checkout — and my checkout is behind (pushedAton the repo is newer than my latest local commit). The only related hit is a barewindow.open('https://keepkey.com/launch')atpages/side-panel/src/components/Connect.tsx:60, which is not the source of the composed message.So this is filed from the observed error string rather than from the code. Whoever picks it up should grep a current tree for the message text and walk back to the caller treating it as an object.
Reproduction
TypeErrorin place of the intended guidanceWhy it's worth fixing
"Vault not running" is probably one of the most common states a new user hits, and the one case where the product already knows exactly what to tell them. Right now that instruction is unreadable, which turns a self-service fix into a support ticket.