Summary
A "no tab is open on this host" condition is reported to CLI users as a version mismatch, sending them to update software that is not the problem.
Observed
@fetchproxy/cli@1.4.0, server 1.11.0:
$ fpx post-json https://api.creditkarma.com/graphql @body.json -p creditkarma
bridge error (protocol): no tab matching https://api.creditkarma.com/ — extension/server version mismatch — update both.
Both were current. There was no mismatch. The actual condition was simply that no tab matched.
Cause
packages/server/src/error-kind.ts:88 classifies this correctly:
if (/^no tab matching /.test(error)) {
return 'no_tab';
}
but the CLI's hint table (packages/cli/src/bridge-errors.ts:47-53) has no no_tab key:
const hints: Record<string, string> = {
bridge_down: 'is Chrome running with the Transporter extension installed?',
timeout: 'is a tab open on the declared domain and signed in?',
protocol: 'extension/server version mismatch — update both.',
http: '',
other: '',
};
so the error surfaces under protocol and inherits the blanket version hint.
This is a known pattern in this file
The comment immediately above (bridge-errors.ts:35-38) describes fixing exactly this misdirection for scope errors:
A widened declared scope is rejected by the extension's gate #2 until the user re-approves. That arrives as a protocol error, so without this it inherits the blanket "version mismatch — update both" hint below and sends people chasing a version problem that does not exist.
no_tab needs the same treatment.
Suggested fix
Add the key, so the hint names the real remedy:
no_tab: 'open a tab on that host and sign in.',
The timeout hint already has the right shape and wording to borrow from. Worth auditing the other kinds error-kind.ts can return against the hint table at the same time, since anything else missing falls into the same trap.
Related: #203 covers the case where opening such a tab is impossible because the host serves no page.
🤖 Generated with Claude Code
Summary
A "no tab is open on this host" condition is reported to CLI users as a version mismatch, sending them to update software that is not the problem.
Observed
@fetchproxy/cli@1.4.0, server 1.11.0:Both were current. There was no mismatch. The actual condition was simply that no tab matched.
Cause
packages/server/src/error-kind.ts:88classifies this correctly:but the CLI's hint table (
packages/cli/src/bridge-errors.ts:47-53) has nono_tabkey:so the error surfaces under
protocoland inherits the blanket version hint.This is a known pattern in this file
The comment immediately above (bridge-errors.ts:35-38) describes fixing exactly this misdirection for scope errors:
no_tabneeds the same treatment.Suggested fix
Add the key, so the hint names the real remedy:
The
timeouthint already has the right shape and wording to borrow from. Worth auditing the other kindserror-kind.tscan return against the hint table at the same time, since anything else missing falls into the same trap.Related: #203 covers the case where opening such a tab is impossible because the host serves no page.
🤖 Generated with Claude Code