jackwener/OpenCLI · error · CommandExecutionError

weibo delete: HTTP ${result.status}

Error message

weibo delete: HTTP ${result.status}

What it means

clis/weibo/delete.js:158 throws CommandExecutionError(`weibo delete: HTTP ${result.status}`) when any of the underlying page fetches (show, destroy, or verify) returned a non-OK HTTP status (error==='show_http'|'destroy_http'|'verify_http'). It reports which stage failed only via the numeric status, keeping auth and not_found as separate, more specific errors.

Source

Thrown at clis/weibo/delete.js:158

          return { ok: false, error: 'verify_malformed', msg: 'verify returned malformed response', id: idstr };
        }
        if (String(verifyBody.idstr || '') === idstr) {
          return { ok: false, error: 'still_exists', id: idstr, mblogid: verifyBody.mblogid || mblogid };
        }
        if (!verifyBody.idstr || verifyBody.ok === 0) {
          return { ok: true, id: idstr, mblogid };
        }
        return { ok: false, error: 'verify_mismatch', msg: 'verify returned a different post id', id: idstr };
      })()
    `)), 'weibo delete');
        if (result.error === 'auth') {
            throw new AuthRequiredError('weibo.com', 'Cookie 已过期！请在当前 Chrome 浏览器中重新登录 Weibo。');
        }
        if (result.error === 'not_found') {
            throw new EmptyResultError('weibo delete', `Post not found for id "${String(result.input ?? raw)}". Verify the post still exists and belongs to the logged-in account.`);
        }
        if (result.error === 'show_http' || result.error === 'destroy_http' || result.error === 'verify_http') {
            throw new CommandExecutionError(`weibo delete: HTTP ${result.status}`);
        }
        if (result.error === 'api' || result.error === 'verify_malformed' || result.error === 'verify_mismatch' || result.error === 'still_exists') {
            throw new CommandExecutionError(`weibo delete: ${String(result.msg ?? result.error)}`);
        }
        if (!result.ok) {
            throw new CommandExecutionError('weibo delete returned an unexpected response');
        }
        return [{ status: 'deleted', id: String(result.id ?? ''), mblogid: String(result.mblogid ?? '') }];
    },
});

export const __test__ = {
    normalizePostId,
};

View on GitHub (pinned to 49907e53dc)

Solutions

1. Check result.status in the error: for 403/429 slow down, add delays between deletes, and retry after minutes
2. Refresh the weibo.com session in Chrome (reload the page, confirm you can delete manually) to pick up fresh tokens
3. For 404 on show, verify the post id — the post may be gone (see the not_found path)
4. For persistent 5xx, retry later; check if Weibo changed its endpoints and update the CLI

Example fix

// before: hammering the API in a loop
for (const id of ids) await cli.run('weibo delete', { id });
// after: throttle + status-aware retry
for (const id of ids) {
  try { await cli.run('weibo delete', { id }); }
  catch (e) {
    if (/HTTP (403|429)/.test(e.message)) { await sleep(60000); continue; }
    throw e;
  }
  await sleep(3000);
}

function isHttpDeleteError(e) { return e instanceof Error && /weibo delete: HTTP \d+/.test(e.message); }
function httpStatus(e) { const m = /HTTP (\d+)/.exec(e.message); return m ? Number(m[1]) : 0; }

const RETRYABLE = new Set([403, 418, 429, 500, 502, 503, 504]);
for (let attempt = 0; attempt < 3; attempt++) {
  try { return await cli.run('weibo delete', { id }); }
  catch (e) {
    if (isHttpDeleteError(e) && RETRYABLE.has(httpStatus(e))) { await new Promise(r => setTimeout(r, 15000 * (attempt + 1))); continue; }
    throw e;
  }
}

When it happens

Trigger: The in-page fetch to weibo.com's /aj/mblog/del, /ajax/statuses/show, or the verify step returned 4xx/5xx — e.g. 403 risk-control rejection, 418/429 rate limiting, 404 on show, or 5xx server error.

Common situations: Deleting many posts in a loop triggers Weibo rate limiting/risk control (403/429); Weibo API surface changed and an endpoint now returns 404; transient 5xx during Weibo incidents; stale CSRF tokens after long-idle sessions.

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

• autohome ${contextHint} HTTP ${resp.status}
• Ctrip flight API returned HTTP ${status || 'unknown'}
• dongchedi ${contextHint} HTTP ${resp.status}
• eastmoney convertible failed: HTTP ${resp.status}
• HTTP_ERROR

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