jackwener/OpenCLI · error · CommandExecutionError
HTTP ${probe.httpStatus} from Quark account/info
Error message
HTTP ${probe.httpStatus} from Quark account/info What it means
verifyQuarkIdentity probes the logged-in Quark (pan.quark.cn) page via WHOAMI_PROBE, which calls the account/info endpoint from page context. When that HTTP request returns a non-2xx status, the probe reports kind 'http' and this CommandExecutionError is thrown with the status code embedded. It means the identity check could not complete because the Quark API rejected or failed the request at the transport level (not an auth redirect and not a JS exception).
Source
Thrown at clis/quark/auth.js:29
if (!r.ok) return { kind: 'http', httpStatus: r.status };
const d = await r.json();
const data = d && d.data;
const isEmpty = !data || Array.isArray(data) || Object.keys(data).length === 0;
if (isEmpty) return { kind: 'auth', detail: 'Quark account/info returned empty data — anonymous' };
const nickname = String(data.nickname || data.nick_name || data.name || '');
if (!nickname) return { kind: 'render-error', detail: 'Quark account/info populated but no nickname field — response shape drift' };
return { ok: true, nickname };
} catch (e) {
return { kind: 'exception', detail: String(e && e.message || e) };
}
})()`;
async function verifyQuarkIdentity(page) {
await page.goto('https://pan.quark.cn/');
await page.wait(2);
const probe = await page.evaluate(WHOAMI_PROBE);
if (probe?.kind === 'auth') throw new AuthRequiredError('quark.cn', probe.detail);
if (probe?.kind === 'http') throw new CommandExecutionError(`HTTP ${probe.httpStatus} from Quark account/info`);
if (probe?.kind === 'render-error') throw new CommandExecutionError(probe.detail);
if (probe?.kind === 'exception') throw new CommandExecutionError(`Quark whoami failed: ${probe.detail}`);
if (!probe?.ok) throw new CommandExecutionError(`Unexpected Quark probe: ${JSON.stringify(probe)}`);
return { nickname: probe.nickname };
}
registerSiteAuthCommands({
site: 'quark',
domain: 'quark.cn',
loginUrl: 'https://pan.quark.cn/',
columns: ['nickname'],
verify: verifyQuarkIdentity,
poll: async (page) => {
const probe = await page.evaluate(WHOAMI_PROBE);
if (!probe?.ok) throw new AuthRequiredError('quark.cn', 'Waiting for Quark login');
return { nickname: probe.nickname };
},
});View on GitHub (pinned to 49907e53dc)
Solutions
- Retry after a delay — transient 429/5xx responses are the most common cause; back off and re-run the identity check.
- Verify the browser session is valid by opening pan.quark.cn in the automated page and confirming you are logged in; re-authenticate if cookies were cleared (AuthRequiredError would normally cover this, but odd statuses can stem from half-valid sessions).
- Inspect probe.httpStatus to identify the cause: 429 = slow down, 403 = blocked/WAF, 5xx = server-side, and act accordingly.
- Update the library/WHOAMI_PROBE if Quark changed its account/info endpoint, since an old URL can yield 404.
- Check network/proxy configuration between the automation environment and quark.cn.
Example fix
// before
await cli.run(['quark', 'whoami']); // throws CommandExecutionError on HTTP 429
// after
try {
await cli.run(['quark', 'whoami']);
} catch (e) {
if (String(e.message).includes('HTTP 429')) {
await new Promise(r => setTimeout(r, 30_000));
await cli.run(['quark', 'whoami']);
} else throw e;
} Defensive patterns
Strategy: retry
Validate before calling
// Best-effort pre-check: ensure a session cookie for quark.cn exists before probing
const cookies = await page.cookies('https://pan.quark.cn/');
if (!cookies.some(c => /session|token|__pus/i.test(c.name))) {
throw new Error('No Quark session cookie; run `quark login` first');
} Type guard
function isHttpProbe(p) {
return !!p && typeof p === 'object' && p.kind === 'http' && typeof p.httpStatus === 'number';
} Try / catch
try {
await verifyQuarkIdentity(page);
} catch (e) {
const m = /HTTP (\d{3}) from Quark/.exec(String(e.message));
if (m && (m[1] === '429' || m[1].startsWith('5'))) {
await sleep(30000); // back off and retry transient statuses
} else {
throw e;
}
} Prevention
- Reuse a warm, logged-in browser profile so requests look routine
- Apply exponential backoff on 429/5xx instead of immediate retries
- Keep the tool updated so WHOAMI_PROBE targets the current Quark API URL
- Check probe.httpStatus in logs to classify failures before acting
When it happens
Trigger: WHOAMI_PROBE's fetch of Quark account/info returns an HTTP error status (e.g. 403, 429, 5xx) during verifyQuarkIdentity, typically when running the quark whoami/identity verification command against pan.quark.cn.
Common situations: Quark rate-limiting or WAF blocking automated requests; Quark API returning 5xx during outage or maintenance; regional/CDN blocks; expired cookies producing a non-redirect error status; API endpoint contract change after a Quark frontend update.
Understand the failure class
Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.
Related errors
- 12306 queryByTrainNo returned HTTP ${resp.status}
- 12306 queryByTrainNo returned non-JSON body
- 12306 ${endpoint} returned non-JSON body
- 1point3acres request failed: HTTP ${res.status} ${res.status
- ${label} returned HTTP ${resp.status}: ${summarizeApiError(p
AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29).
Data as JSON: /api/errors/c68e7a12a8558379.
Report an issue: GitHub.