Rectangle requires 4 values: min_x,min_y,max_x,max_y (got {}

Error message

Rectangle requires 4 values: min_x,min_y,max_x,max_y (got {})

What it means

parse_bounds in the survivors command rejects a rectangle zone whose --bounds string does not contain exactly 4 comma-separated f64 values (min_x,min_y,max_x,max_y). The count check runs after every segment is parsed as f64, so a non-numeric segment fails earlier with 'Failed to parse bounds values as numbers'; this error is purely about arity.

Source

Thrown at v2/crates/wifi-densepose-cli/src/mat.rs:809

            println!("{} Zone '{}' resumed.", "[OK]".green().bold(), zone.cyan());
        }
    }

    Ok(())
}

/// Parse bounds string into ZoneBounds
fn parse_bounds(zone_type: &ZoneType, bounds: &str) -> Result<ZoneBounds> {
    let parts: Vec<f64> = bounds
        .split(',')
        .map(|s| s.trim().parse::<f64>())
        .collect::<std::result::Result<Vec<_>, _>>()
        .context("Failed to parse bounds values as numbers")?;

    match zone_type {
        ZoneType::Rectangle => {
            if parts.len() != 4 {
                anyhow::bail!(
                    "Rectangle requires 4 values: min_x,min_y,max_x,max_y (got {})",
                    parts.len()
                );
            }
            Ok(ZoneBounds::rectangle(
                parts[0], parts[1], parts[2], parts[3],
            ))
        }
        ZoneType::Circle => {
            if parts.len() != 3 {
                anyhow::bail!(
                    "Circle requires 3 values: center_x,center_y,radius (got {})",
                    parts.len()
                );
            }
            Ok(ZoneBounds::circle(parts[0], parts[1], parts[2]))
        }
    }

View on GitHub (pinned to 4685618388)

Solutions

Count the comma-separated values: a rectangle needs exactly min_x,min_y,max_x,max_y
Use the 3-value center_x,center_y,radius form only with the circle zone type
Quote the whole bounds string so the shell passes it as one argument
After fixing the count, verify min < max ordering — inverted bounds are accepted but yield an empty zone

Example fix

// before
$ ruview survivors --type rectangle --bounds '0,0,10'

// after
$ ruview survivors --type rectangle --bounds '0,0,10,10'

Defensive patterns

Strategy: validation

Validate before calling

fn rectangle_bounds_ok(bounds: &str) -> bool {
    bounds
        .split(',')
        .filter(|s| s.trim().parse::<f64>().is_ok())
        .count()
        == 4
}

Type guard

enum ZoneSpec {
    Rect([f64; 4]),
    Circle([f64; 3]),
}

fn parse_zone_spec(kind: &str, bounds: &str) -> Option<ZoneSpec> {
    let v: Vec<f64> = bounds
        .split(',')
        .map(|s| s.trim().parse())
        .collect::<Result<_, _>>()
        .ok()?;
    match (kind, v.as_slice()) {
        ("rectangle", [a, b, c, d]) => Some(ZoneSpec::Rect([*a, *b, *c, *d])),
        ("circle", [a, b, r]) => Some(ZoneSpec::Circle([*a, *b, *r])),
        _ => None,
    }
}

Prevention

Validate the value count in wrapper scripts before invoking the CLI
Keep one canonical bounds format per zone type in config files
Add a unit test for every zone string shipped in automation

When it happens

Trigger: Passing --bounds '0,0,10' (3 values) or '0,0,10,10,2' (5 values) with a rectangle zone type; copy-pasting circle syntax (3 values) for a rectangle.

Common situations: Scripting the CLI with hand-typed zone strings; mixing rectangle and circle formats between configs; trailing commas (these fail float parsing first, with a different message).

Related errors

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