zeroclaw-labs/zeroclaw · error

missing msgtype

Error message

missing msgtype

What it means

The WeCom WS inbound parser requires a non-empty msgtype field on every payload it normalizes; a missing or empty string bails immediately, guarding the downstream dispatch that switches on message type.

Source

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

    if pad_len == 0 || pad_len > 32 || pad_len > input.len() {
        anyhow::bail!("invalid WeCom padding length");
    }
    Ok(&input[..input.len() - pad_len])
}

fn is_wecom_data_version_conflict_error(err: &anyhow::Error) -> bool {
    let msg = err.to_string();
    msg.contains("errcode=6000") || msg.contains("data version conflict")
}

fn parse_inbound_payload(payload: Value) -> Result<ParsedInbound> {
    let msg_type = payload
        .get("msgtype")
        .and_then(Value::as_str)
        .unwrap_or("")
        .to_string();
    if msg_type.is_empty() {
        anyhow::bail!("missing msgtype");
    }

    let msg_id = payload
        .get("msgid")
        .and_then(Value::as_str)
        .unwrap_or("")
        .to_string();

    let chat_type = payload
        .get("chattype")
        .and_then(Value::as_str)
        .unwrap_or("single")
        .to_string();

    let chat_id = payload
        .get("chatid")
        .and_then(Value::as_str)
        .map(ToOwned::to_owned);

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Log the raw payload (msg_id is parsed nearby) and identify which WeCom event lacks msgtype
2. Skip non-message events instead of failing the whole inbound batch
3. Report or patch the parser if the payload is a legitimate new event type
4. Check for JSON mangling middleware if msgtype should be present

// Pre-check the raw payload before handing it to the normalizer
let has_msgtype = payload
    .get("msgtype")
    .and_then(|v| v.as_str())
    .is_some_and(|s| !s.is_empty());
if !has_msgtype {
    debug!("skipping non-message event: {payload}");
    return Ok(None);
}

Parse each inbound payload independently; on 'missing msgtype' log the raw JSON and continue with the next message instead of propagating out of the receive loop.

When it happens

Trigger: A WeCom callback/event payload without msgtype — control frames, status events, or new message types — or a schema change renaming the field; occasionally a mangled JSON body.

Common situations: WeCom introducing event payloads the parser does not model yet; version skew between the WeCom API and this channel; a proxy altering the JSON body.

Understand the failure class

Background: "Missing required field" and "field is required" errors: why libraries reject payloads that omit mandatory fields — this error's family across 20 libraries.

Related errors

• inbound attachment exceeds {} MB limit
• WeCom max_file_size_bytes is zero
• WeCom attachment download failed: kind={} msg_id={} url_targ
• WeCom: invalid scope format: {scope}
• capability '{}' requires authored `with` configuration to be

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