ruvnet/RuView · error · anyhow::Error

HAP was requested but this binary was built without the `hap

Error message

HAP was requested but this binary was built without the `hap-server` feature

What it means

Anyhow bail in homecore-server's HAP startup: HAP was requested in the CLI config, but the binary was compiled without the `hap-server` cargo feature, so the code that would start the HomeKit bridge (start_server, MdnsSdAdvertiser, PairingStore from homecore_hap) does not exist in this build. When HAP is disabled the function returns a stub HapRuntime instead; this error fires only for the enabled-but-not-compiled combination.

Source

Thrown at v2/crates/homecore-server/src/hap.rs:59

        Ok(())
    }
}

pub(crate) async fn start(hc: &HomeCore, config: HapRuntimeConfig) -> Result<HapRuntime> {
    let Some(bind_addr) = config.bind_addr else {
        tracing::info!("HAP network server disabled");
        return Ok(HapRuntime {
            #[cfg(feature = "hap-server")]
            handle: None,
            #[cfg(feature = "hap-server")]
            state_task: None,
        });
    };

    #[cfg(not(feature = "hap-server"))]
    {
        let _ = (hc, bind_addr);
        anyhow::bail!(
            "HAP was requested but this binary was built without the `hap-server` feature"
        );
    }

    #[cfg(feature = "hap-server")]
    {
        use std::sync::Arc;

        use homecore_hap::{
            start_server, HapBridge, HapServerConfig, HapServiceRecord, MdnsSdAdvertiser,
            PairingStore,
        };

        let device_id = config
            .device_id
            .as_deref()
            .ok_or_else(|| anyhow::anyhow!("--hap-device-id is required when HAP is enabled"))?;
        let advertise_addr = config.advertise_addr.ok_or_else(|| {

View on GitHub (pinned to 4685618388)

Solutions

1. Rebuild the server with the feature: cargo build --release --features hap-server (add it to your Dockerfile/CI invocation)
2. Or stop requesting HAP: remove/drop the --hap-* flags so the disabled-HAP path returns the stub runtime
3. Check the package's feature list (cargo metadata or docs) to confirm the exact feature name in your version
4. If you installed from a package manager, look for a variant package that includes HAP support

Example fix

# before
cargo build --release
# ./homecore-server --hap-enable ... -> HAP was requested but built without `hap-server`

# after
cargo build --release --features hap-server
# ./homecore-server --hap-enable ... -> HAP bridge starts

# preflight: confirm the running binary was built with hap-server before enabling HAP
# (cheap CLI probe; builds without the feature reject the HAP flags)
if ! homecore-server --help 2>&1 | grep -q -- '--hap-device-id'; then
  echo 'binary lacks hap-server feature; rebuild with --features hap-server' >&2
  exit 1
fi

let hap = match hap::start(hc, hap_config).await {
    Ok(runtime) => runtime,
    Err(e) if e.to_string().contains('hap-server') => {
        tracing::warn!("HAP unavailable in this build; continuing without it: {e}");
        HapRuntime::disabled()
    }
    Err(e) => return Err(e),
};

When it happens

Trigger: Running a binary built with default features while passing HAP-enabling flags (e.g. --hap-device-id); distro/CI artifacts commonly omit optional heavy features like hap-server; a Docker image built from a minimal feature set.

Common situations: Prebuilt release binaries that do not bundle hap-server; feature flags lost when reproducing a build (missing --features flag in CI or Dockerfile); copy-pasting a systemd unit that enables HAP onto a host with a non-HAP binary.

Related errors

• --hap-device-id is required when HAP is enabled
• --hap-advertise-addr is required when HAP is enabled
• --hap-setup-code is required when creating a HAP pairing sto
• plugin directories were configured, but homecore-server was
• plugin trust options were configured, but homecore-server wa

AI-assisted analysis of ruvnet/RuView@4685618388 (2026-08-16). Data as JSON: /api/errors/3bd1611ed030f13e. Report an issue: GitHub.