databendlabs/databend · error

linestring geometry

Error message

linestring geometry

What it means

Same pattern as the point aggregate: in geographic aggregate `compute`, when all input geometries are `Geometry::LineString(_)`, each is converted to `LineString<f64>` via `try_into().expect("linestring geometry")`. The preceding `matches!` guard should guarantee success, so the panic signals a broken conversion impl or malformed linestring data. It's an internal assertion guarding the all-LineString fast path that builds a MultiLineString.

Solutions

  1. Check linestring inputs for degenerate/empty coordinate lists that the converter rejects.
  2. Confirm the geo crate TryFrom impl matches the library's expected behavior for the version in use.
  3. Convert the expect to a propagated error so bad data surfaces as a query error instead of a panic.

Example fix

// before
.map(|geo| geo.try_into().expect("linestring geometry"))
// after
.map(|geo| geo.try_into().map_err(|e| ErrorCode::BadArguments(format!("linestring geometry: {e}"))))
.collect::<Result<Vec<_>, _>>()?;
Defensive patterns

Strategy: validation

Validate before calling

// caller-side check before aggregating:
let all_valid_lines = geos.iter().all(|g| matches!(g, Geometry::LineString(l) if !l.coords().is_empty()));

Type guard

fn is_nonempty_linestring(g: &Geometry) -> bool { matches!(g, Geometry::LineString(l) if l.coords().count() > 0) }

Try / catch

let result = std::panic::catch_unwind(|| aggregate_linestrings(geos.clone()));

Prevention

When it happens

Trigger: Aggregating LineString geometries where the `TryFrom<Geometry> for LineString<f64>` conversion unexpectedly fails despite the type guard — e.g. linestrings with fewer than required coordinates or invalid interior data.

Common situations: Ingesting degenerate linestrings (zero points) from external geometry sources; geo crate version drift changing conversion acceptance; corrupted serialized geometries.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of databendlabs/databend@288d84d76e (2026-09-11). Data as JSON: /api/errors/a39edf5653bcacb6. Report an issue: GitHub.

Appendix: source

Thrown at src/query/expression/src/geographic/aggregate.rs:104

        if geos.is_empty() {
            return Ok(None);
        }

        if geos.iter().all(|geo| matches!(geo, Geometry::Point(_))) {
            let points: Vec<Point<f64>> = geos
                .into_iter()
                .map(|geo| geo.try_into().expect("point geometry"))
                .collect();
            let multi_point = MultiPoint::from_iter(points);
            return Ok(Some(Geometry::MultiPoint(multi_point)));
        }
        if geos
            .iter()
            .all(|geo| matches!(geo, Geometry::LineString(_)))
        {
            let lines: Vec<LineString<f64>> = geos
                .into_iter()
                .map(|geo| geo.try_into().expect("linestring geometry"))
                .collect();
            let multi_line_string = MultiLineString::from_iter(lines);
            return Ok(Some(Geometry::MultiLineString(multi_line_string)));
        }
        if geos.iter().all(|geo| matches!(geo, Geometry::Polygon(_))) {
            let polygons: Vec<Polygon<f64>> = geos
                .into_iter()
                .map(|geo| geo.try_into().expect("polygon geometry"))
                .collect();
            let multi_polygon = MultiPolygon::from_iter(polygons);
            return Ok(Some(Geometry::MultiPolygon(multi_polygon)));
        }

        let collection = GeometryCollection::from_iter(geos);
        Ok(Some(Geometry::GeometryCollection(collection)))
    }

    fn binary_compute(l_geo: Geometry<f64>, r_geo: Geometry<f64>) -> Result<Option<Geometry<f64>>> {

View on GitHub (pinned to 288d84d76e)