BigPizzaV3/CodexPlusPlus · error · anyhow::Error

{label}超过大小限制

Error message

{label}超过大小限制

What it means

read_response_limited streams the HTTP body and hard-caps it at a caller-supplied max_bytes (1 MiB for send_text via MAX_SMALL_RESPONSE_BYTES, 64 MiB for the polling paths via MAX_API_RESPONSE_BYTES). When cumulative bytes exceed the cap it bails with '{label}超过大小限制'. It is a deliberate memory guard against unbounded responses.

Source

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

        .render::<qrcode::render::svg::Color>()
        .min_dimensions(320, 320)
        .dark_color(qrcode::render::svg::Color("#111827"))
        .light_color(qrcode::render::svg::Color("#ffffff"))
        .build())
}

async fn read_response_limited(
    response: reqwest::Response,
    max_bytes: usize,
    label: &str,
) -> anyhow::Result<(reqwest::StatusCode, Vec<u8>)> {
    let status = response.status();
    let mut stream = response.bytes_stream();
    let mut bytes = Vec::new();
    while let Some(chunk) = stream.next().await {
        let chunk = chunk.with_context(|| format!("读取{label}失败"))?;
        if bytes.len().saturating_add(chunk.len()) > max_bytes {
            bail!("{label}超过大小限制");
        }
        bytes.extend_from_slice(&chunk);
    }
    Ok((status, bytes))
}

impl WeixinMessage {
    pub fn is_finished_user_message(&self) -> bool {
        self.message_type == 1 && self.message_state == 2 && !self.from_user_id.trim().is_empty()
    }

    pub fn text(&self) -> Option<String> {
        self.item_list.iter().find_map(message_item_text)
    }

    pub fn dedup_key(&self) -> String {
        format!(
            "{}|{}|{}|{}|{}",

View on GitHub (pinned to f2074595a2)

Solutions

1. Verify base_url points at the genuine WeChat ilink API origin with no intercepting proxy
2. Poll more frequently so the pending message buffer stays far below 64 MiB
3. Treat as transient: re-poll once after a short backoff; if it recurs at the same step, inspect the actual response with curl -D against the same URL
4. Do not raise the constants to make it go away - the cap is the memory-safety guard

Catch the error from the weixin call and test whether the message ends with '超过大小限制'; the {label} prefix names the endpoint that tripped it. Re-poll once after a delay, then stop and report the label plus the configured base_url - a persistent size failure means the body is not coming from the real API.

When it happens

Trigger: The send endpoint returning more than 1 MiB (for example an HTML error or captive-portal page because base_url is wrong); get_updates returning a message backlog larger than 64 MiB; an intercepting proxy replacing the API response.

Common situations: base_url pointed at a proxy or antivirus gateway that injects large pages; infrequent polling letting the longpoll backlog grow; captive enterprise or hotel networks intercepting the connection.

Related errors

• 发送微信回复被拒绝：ret={} errcode={} {}
• invalid Dream Skin destination name
• Dream Skin image is not a file
• Dream Skin image is empty
• Dream Skin source image exceeds 50 MiB

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