BigPizzaV3/CodexPlusPlus · error · anyhow::Error

微信长轮询请求失败：HTTP {http_status}

Error message

微信长轮询请求失败：HTTP {http_status}

What it means

get_updates POSTs the long-poll request; reqwest-level timeouts are tolerated and returned as an empty updates batch, so this error is specifically a non-2xx HTTP status from the getupdates endpoint. The caller run_weixin_connect records it in status and retries after 2 seconds, so single occurrences self-heal.

Source

Thrown at crates/codex-plus-core/src/connect/weixin.rs:234

            .await;
        let response = match response {
            Ok(response) => response,
            Err(error) if error.is_timeout() => {
                return Ok(WeixinUpdates {
                    ret: 0,
                    errcode: 0,
                    errmsg: String::new(),
                    messages: Vec::new(),
                    get_updates_buf: get_updates_buf.to_string(),
                    longpolling_timeout_ms: timeout_ms,
                });
            }
            Err(error) => return Err(error).context("微信长轮询请求失败"),
        };
        let (http_status, bytes) =
            read_response_limited(response, MAX_API_RESPONSE_BYTES, "微信长轮询").await?;
        if !http_status.is_success() {
            bail!("微信长轮询请求失败：HTTP {http_status}");
        }
        let updates: WeixinUpdates =
            serde_json::from_slice(&bytes).context("微信长轮询响应格式无效")?;
        if updates.ret != 0 || updates.errcode != 0 {
            bail!(
                "微信长轮询被拒绝：ret={} errcode={} {}",
                updates.ret,
                updates.errcode,
                updates.errmsg
            );
        }
        Ok(updates)
    }

    pub async fn send_text_chunks(
        &self,
        to_user_id: &str,
        text: &str,

View on GitHub (pinned to f2074595a2)

Solutions

1. If it persists, re-login by fetching a new QR code and token
2. Let the built-in 2s retry ride out transient 5xx and watch status.message in the manager
3. Reset the persisted connect state when get_updates_buf is suspected corrupt
4. Verify base_url and route_tag

// the connector already does this: log, wait, poll again
match client.get_updates(&state.get_updates_buf, timeout_ms).await {
    Ok(u) => u,
    Err(e) if e.to_string().contains("HTTP ") => {
        status_message(format!("retrying: {e}"));
        tokio::time::sleep(Duration::from_secs(2)).await;
        continue;
    }
    Err(e) => return Err(e),
}

When it happens

Trigger: An invalid or expired token making the gateway answer 401 or 403; gateway 5xx; a malformed get_updates_buf after state corruption; wrong base_url.

Common situations: WeChat session expired and needs a re-scan; ilink outage; connector resumed with a stale get_updates_buf.

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

• 获取微信登录二维码失败：HTTP {status}
• 查询微信扫码状态失败：HTTP {status}
• 微信长轮询被拒绝：ret={} errcode={} {}
• 发送微信回复失败：HTTP {http_status}
• 请先扫码登录微信

AI-assisted analysis of BigPizzaV3/CodexPlusPlus@f2074595a2 (2026-08-23). Data as JSON: /api/errors/db18fda5de281421. Report an issue: GitHub.