zeroclaw-labs/zeroclaw · error

WeCom max_file_size_bytes is zero

Error message

WeCom max_file_size_bytes is zero

What it means

WeCom WS attachment handling compares downloaded size against cfg.max_file_size_bytes; a zero limit would make the check meaningless, so download_and_store_attachment refuses to run and bails immediately. It is a config sanity guard tripped on the first inbound attachment after startup.

Source

Thrown at crates/zeroclaw-channels/src/wecom_ws.rs:1285

            other => {
                wecom_log_info!(
                    "[wecom_ws] unsupported msg_type={other}, raw_payload={}",
                    inbound.raw_payload
                );
                NormalizedMessage::Unsupported
            }
        }
    }

    async fn download_and_store_attachment(
        &self,
        url: &str,
        kind: AttachmentKind,
        inbound: &ParsedInbound,
        aeskey: Option<&str>,
    ) -> Result<String> {
        if self.cfg.max_file_size_bytes == 0 {
            anyhow::bail!("WeCom max_file_size_bytes is zero");
        }

        let started = Instant::now();
        let chat_id = inbound.chat_id.as_deref().unwrap_or("single");
        let url_target = summarize_attachment_url_for_log(url);
        wecom_log_info!(
            "WeCom attachment download started msg_id={} msg_type={} chat_type={} chat_id={} sender_userid={} attachment_kind={} url_target={} has_aeskey={} timeout_secs={}",
            inbound.msg_id,
            inbound.msg_type,
            inbound.chat_type,
            chat_id,
            inbound.sender_userid,
            kind.as_str(),
            url_target,
            aeskey.is_some(),
            WECOM_HTTP_TIMEOUT_SECS
        );

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Set max_file_size_bytes to an explicit positive limit (e.g. 10485760 = 10 MB) in the wecom_ws channel config
  2. Size the limit against WeCom media constraints and local disk budget
  3. Reload/restart the channel after the config change

Example fix

# before
[channels.wecom_ws]
max_file_size_bytes = 0
# after
[channels.wecom_ws]
max_file_size_bytes = 10485760
Defensive patterns

Strategy: validation

Validate before calling

fn wecom_file_limit_ok(limit: u64) -> bool { limit > 0 }
if !wecom_file_limit_ok(cfg.max_file_size_bytes) {
    return Err(anyhow::anyhow!(
        "max_file_size_bytes must be > 0 (got 0)"
    ));
}

Try / catch

Treat as a startup config error: validate before enabling the channel so the first inbound attachment does not discover it.

Prevention

When it happens

Trigger: wecom_ws channel configured with max_file_size_bytes unset or 0 (bad TOML default, typo'd key, or 0 intended to mean 'unlimited') and any inbound message with media arrives.

Common situations: Users set 0 expecting 'no limit'; a config migration dropped the key; templates ship a placeholder 0; the key name was renamed and the old key silently ignored.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors


AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/fb79ea3839ff8194. Report an issue: GitHub.