What causes "Invalid {key} '{value}': expected {min}-{max}" in Hmbown/CodeWhale?

Re-issue the set with a plain integer inside the advertised min-max window (no units, no separators).

Invalid {key} '{value}': expected {min}-{max}

Error message

Invalid {key} '{value}': expected {min}-{max}

What it means

Thrown by parse_u16_range when a u16-bounded TUI setting receives a value that either fails u16 parsing or falls outside the [min, max] window the setting declares. The parse failure and the range failure produce the identical message, so 'expected {min}-{max}' also covers non-numeric input. Bounds come from the caller, so the message always states the real window.

Source

Thrown at crates/tui/src/settings.rs:2586

fn default_true() -> bool {
    true
}

fn parse_usize_setting(key: &str, value: &str) -> Result<usize> {
    value.trim().parse::<usize>().map_err(|_| {
        anyhow::anyhow!(
            "Failed to update setting: invalid {key} '{value}'. Expected 0 or a positive integer."
        )
    })
}

fn parse_u16_range(key: &str, value: &str, min: u16, max: u16) -> Result<u16> {
    let parsed = value
        .trim()
        .parse::<u16>()
        .map_err(|_| anyhow::anyhow!("Invalid {key} '{value}': expected {min}-{max}"))?;
    if !(min..=max).contains(&parsed) {
        anyhow::bail!("Invalid {key} '{value}': expected {min}-{max}");
    }
    Ok(parsed)
}

fn parse_percent_setting(key: &str, value: &str) -> Result<f64> {
    let trimmed = value.trim().trim_end_matches('%').trim();
    let percent = trimmed.parse::<f64>().map_err(|_| {
        anyhow::anyhow!(
            "Failed to update setting: invalid {key} '{value}'. Expected a number from 10 to 100."
        )
    })?;
    if !(10.0..=100.0).contains(&percent) {
        anyhow::bail!(
            "Failed to update setting: invalid {key} '{value}'. Expected a number from 10 to 100."
        );
    }
    Ok(percent)
}

View on GitHub (pinned to 0c42157ee5)

Solutions

Re-issue the set with a plain integer inside the advertised min-max window (no units, no separators).
If you intended 0, check whether this key routes through the sibling '0 or a positive integer' parser instead.
Strip whitespace and units before sending; the parser trims outer whitespace but nothing else.
For wrappers, parse and range-check the value client-side before issuing the set.

Example fix

# before
:set history_limit 99999

# after (window advertised by the error, e.g. 1-10000)
:set history_limit 10000

Defensive patterns

Strategy: validation

Validate before calling

fn in_u16_window(value: &str, min: u16, max: u16) -> bool {
    matches!(value.trim().parse::<u16>(), Ok(v) if (min..=max).contains(&v))
}

Try / catch

match parse_u16_range(key, value, min, max) {
    Err(err) if err.to_string().starts_with("Invalid") => retry_with_corrected_value(),
    other => other?,
}

Prevention

Range-check numeric config in the wrapper before sending it to the TUI.
Remember u16 rejects signs and values above 65535 at parse time.
Keep the advertised window in the error copy in sync with the schema.

When it happens

Trigger: Calling ':set <u16-key> <value>' where the value is not an in-range u16: '70000' (overflows u16), '-1' (u16 rejects signs), 'abc', or an in-type but out-of-window value like '0' when the key's declared min is 1.

Common situations: Port numbers above 65535, counts set to 0 when the schema demands at least 1, decimals like '2.5', thousands separators or trailing units ('8080,' or '10s'), and pasted values with stray whitespace or symbols.

Related errors

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/ff8a8ed83793743a. Report an issue: GitHub.