jackwener/OpenCLI · error · CommandExecutionError

HTTP ${probe.httpStatus} from Gitee /api/v5/user

Error message

HTTP ${probe.httpStatus} from Gitee /api/v5/user

What it means

In verifyGiteeIdentity (clis/gitee/auth.js), when the in-page fetch to https://gitee.com/api/v5/user responds with any non-OK status other than 401/403, the probe yields kind 'http' and this CommandExecutionError is thrown with the actual HTTP status. It means the Gitee API itself rejected the request at the HTTP level rather than reporting an auth problem.

Source

Thrown at clis/gitee/auth.js:24

const WHOAMI_PROBE = `(async () => {
  try {
    const r = await fetch('/api/v5/user', { credentials: 'include', headers: { Accept: 'application/json' } });
    if (r.status === 401 || r.status === 403) return { kind: 'auth', detail: 'Gitee /api/v5/user HTTP ' + r.status };
    if (!r.ok) return { kind: 'http', httpStatus: r.status };
    const d = await r.json();
    if (!d || !d.id || !d.login) return { kind: 'auth', detail: 'Gitee /api/v5/user has no id/login — anonymous' };
    return { ok: true, user_id: String(d.id), username: String(d.login), name: String(d.name || '') };
  } catch (e) {
    return { kind: 'exception', detail: String(e && e.message || e) };
  }
})()`;

async function verifyGiteeIdentity(page) {
  await page.goto('https://gitee.com/');
  await page.wait(1);
  const probe = await page.evaluate(WHOAMI_PROBE);
  if (probe?.kind === 'auth') throw new AuthRequiredError('gitee.com', probe.detail);
  if (probe?.kind === 'http') throw new CommandExecutionError(`HTTP ${probe.httpStatus} from Gitee /api/v5/user`);
  if (probe?.kind === 'exception') throw new CommandExecutionError(`Gitee whoami failed: ${probe.detail}`);
  if (!probe?.ok) throw new CommandExecutionError(`Unexpected Gitee probe: ${JSON.stringify(probe)}`);
  return { user_id: probe.user_id, username: probe.username, name: probe.name };
}

registerSiteAuthCommands({
  site: 'gitee',
  domain: 'gitee.com',
  loginUrl: 'https://gitee.com/login',
  columns: ['user_id', 'username', 'name'],
  verify: verifyGiteeIdentity,
  poll: async (page) => {
    const probe = await page.evaluate(WHOAMI_PROBE);
    if (!probe?.ok) throw new AuthRequiredError('gitee.com', 'Waiting for Gitee login');
    return { user_id: probe.user_id, username: probe.username, name: probe.name };
  },
});

View on GitHub (pinned to 49907e53dc)

Solutions

1. Read the HTTP status in the message and retry after backoff if it is 429 or 5xx.
2. Open https://gitee.com/api/v5/user in a normal browser to see the raw response and confirm the API path still works.
3. Check for a proxy/firewall intercepting the automated browser's requests.
4. Check Gitee status/announcements for an outage or API change; update the probe URL if the API version changed.

Example fix

// before — failing hard on transient HTTP errors
const identity = await verifyGiteeIdentity(page);
// after — retry on retryable statuses
let identity;
for (let i = 0; i < 3; i++) {
  try { identity = await verifyGiteeIdentity(page); break; }
  catch (e) {
    if (!/HTTP (429|5\d\d)/.test(e.message) || i === 2) throw e;
    await new Promise(r => setTimeout(r, 2 ** i * 1000));
  }
}

const res = await fetch('https://gitee.com/api/v5/user');
if (!res.ok) console.warn('Gitee API currently answering HTTP', res.status);

function isRetryableHttp(msg) { return /HTTP (429|5\d\d) /.test(msg); }

try {
  const identity = await verifyGiteeIdentity(page);
} catch (err) {
  const m = err.message.match(/HTTP (\d{3})/);
  if (m && (m[1] === '429' || m[1].startsWith('5'))) {
    await sleep(2000); // then retry with backoff
  } else throw err;
}

When it happens

Trigger: The WHOAMI_PROBE fetch receives a status like 429 (rate limited), 5xx (Gitee server error), 404 (API path changed), or a proxy/WAF block page status while verifying the Gitee identity.

Common situations: Gitee rate limiting after many rapid probes (429); transient Gitee server incidents (5xx); corporate proxy or WAF intercepting requests; Gitee API path/version change breaking /api/v5/user.

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

• REQUEST_FAILED
• HTTP ${r.status} from ${r.where}
• HTTP ${probe.httpStatus} from auth_data
• HTTP ${code}
• 12306 queryByTrainNo returned HTTP ${resp.status}

AI-assisted analysis of jackwener/OpenCLI@49907e53dc (2026-08-29). Data as JSON: /api/errors/cb6f9aa88251c3b6. Report an issue: GitHub.