wasmerio/wasmer · error · anyhow::Error

invalid value for {} - expected 0/false|1/true: '{other}'

Error message

invalid value for {} - expected 0/false|1/true: '{other}'

What it means

WasmerClient::new_with_client parses the env var WASMER_LOG_VARIABLES (Self::ENV_VAR_LOG_VARIABLES) as a boolean flag. Only "1", "true", "0", "false", or empty are accepted; any other value causes a bail with this message naming the env var and offending value.

Source

Thrown at lib/backend-api/src/client.rs:65

        user_agent
            .parse()
            .with_context(|| format!("invalid user agent: '{user_agent}'"))
    }

    pub fn new_with_client(
        client: reqwest::Client,
        graphql_endpoint: Url,
        user_agent: &str,
    ) -> Result<Self, anyhow::Error> {
        let log_variables = {
            let v = std::env::var(Self::ENV_VAR_LOG_VARIABLES).unwrap_or_default();
            match v.as_str() {
                "1" | "true" => true,
                "0" | "false" => false,
                // Default case if not provided.
                "" => false,
                other => {
                    bail!(
                        "invalid value for {} - expected 0/false|1/true: '{other}'",
                        Self::ENV_VAR_LOG_VARIABLES
                    );
                }
            }
        };

        Ok(Self {
            client,
            auth_token: None,
            user_agent: Self::parse_user_agent(user_agent)?,
            graphql_endpoint,
            log_variables,
        })
    }

    pub fn new(graphql_endpoint: Url, user_agent: &str) -> Result<Self, anyhow::Error> {
        Self::new_with_proxy(graphql_endpoint, user_agent, None)

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

  1. Set the env var to exactly "1", "true", "0", "false", or unset it entirely.
  2. Normalize the value before launching: lowercase it and trim whitespace.
  3. If you need richer toggle semantics, propose extending the parser to accept yes/no or case-insensitive true/false.

Example fix

// before
export WASMER_LOG_VARIABLES=yes
// after
export WASMER_LOG_VARIABLES=true
Defensive patterns

Strategy: validation

Validate before calling

fn valid_bool_env(v: &str) -> bool {
    matches!(v.trim().to_ascii_lowercase().as_str(), "" | "0" | "1" | "true" | "false")
}
// check before launching: valid_bool_env(&env::var("WASMER_LOG_VARIABLES").unwrap_or_default())

Prevention

When it happens

Trigger: Setting the log-variables environment variable to anything other than 0/1/true/false/empty — e.g. WASMER_LOG_VARIABLES=yes, on, or True (capitalized) — before creating a WasmerClient.

Common situations: Users setting the toggle to "yes"/"on" out of habit, shell capitalization ("True"), or copy-pasting a value with stray whitespace.

Understand the failure class

Background: "is not a valid" / "Invalid ... value" environment variable errors: how libraries validate env vars and what to do when they reject yours — this error's family across 48 libraries.

Related errors


AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/94e8faf13e30d065. Report an issue: GitHub.