zeroclaw-labs/zeroclaw · error · anyhow::Error

DingTalk channel requires the `channel-dingtalk` feature

Error message

DingTalk channel requires the `channel-dingtalk` feature

What it means

Raised by build_channel_by_id when channel_id = "dingtalk" is requested but the binary lacks the `channel-dingtalk` Cargo feature. The `#[cfg(not(feature = "channel-dingtalk"))]` arm keeps the id recognized and names the missing feature, so the operator gets an actionable message instead of UnknownChannelId. DingTalk construction (DingTalkChannel, including .with_proxy_url support seen in the enabled arm) is cfg'd out entirely.

Source

Thrown at crates/zeroclaw-channels/src/orchestrator/mod.rs:9242

            let alias = "default".to_string();
            let peer_resolver: Arc<dyn Fn() -> Vec<String> + Send + Sync> = {
                let cfg_arc = config_arc.clone();
                let alias = alias.clone();
                Arc::new(move || cfg_arc.read().channel_external_peers("dingtalk", &alias))
            };
            Ok(Arc::new(
                DingTalkChannel::new(
                    dt.client_id.clone(),
                    dt.client_secret.clone(),
                    alias,
                    peer_resolver,
                )
                .with_proxy_url(dt.proxy_url.clone()),
            ))
        }
        #[cfg(not(feature = "channel-dingtalk"))]
        "dingtalk" => {
            anyhow::bail!("DingTalk channel requires the `channel-dingtalk` feature");
        }
        #[cfg(feature = "channel-wecom")]
        "wecom" => {
            let wc = config
                .channels
                .wecom
                .get("default")
                .context("WeCom channel is not configured")?;
            let alias = "default".to_string();
            let peer_resolver: Arc<dyn Fn() -> Vec<String> + Send + Sync> = {
                let cfg_arc = config_arc.clone();
                let alias = alias.clone();
                Arc::new(move || cfg_arc.read().channel_external_peers("wecom", &alias))
            };
            Ok(Arc::new(WeComChannel::new(
                wc.webhook_key.clone(),
                alias,
                peer_resolver,

View on GitHub (pinned to 88bb9c8533)

Solutions

  1. Rebuild with cargo build --release --features channel-dingtalk
  2. Or switch to --features channels-full
  3. Or remove [channels.dingtalk] and the corresponding agent channel bindings
  4. Verify with zeroclaw_channels::listing::is_channel_type_compiled("dingtalk") before startup

Example fix

# before
 cargo build --release

 # after
 cargo build --release --features channel-dingtalk
Defensive patterns

Strategy: validation

Validate before calling

use zeroclaw_channels::listing::is_channel_type_compiled;

if !is_channel_type_compiled("dingtalk") {
    eprintln!("rebuild with --features channel-dingtalk or remove [channels.dingtalk]");
}

Type guard

fn dingtalk_available() -> bool {
    zeroclaw_channels::listing::is_channel_type_compiled("dingtalk")
}

Try / catch

match build_channel_by_id(&config_arc, "dingtalk") {
    Ok(ch) => { /* use */ }
    Err(e) if e.to_string().contains("requires the `channel-dingtalk` feature") => {
        // log rebuild hint; skip channel
    }
    Err(e) => return Err(e),
}

Prevention

When it happens

Trigger: start_channels or build_channel_map hitting the "dingtalk" arm while DingTalkChannel was not compiled: an [channels.dingtalk] block or agent binding selects the id, and the factory can only bail.

Common situations: Default-feature builds (dingtalk is in channels-full only), deploying a config written against a channels-full build onto a slim binary, or CI builds that pin a minimal feature set while the config drifted to add DingTalk.

Related errors

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