read_parquet crashes with 'stoi: no conversion' on GeoParquet files (WASM 1.33.1-dev40.0)

[yharby]

What happens?

read_parquet() on a GeoParquet file crashes with stoi: no conversion in DuckDB-WASM 1.33.1-dev40.0. Even DESCRIBE fails. The same file works fine in DuckDB CLI v1.5.1.

The error happens at the read_parquet() level before any geometry processing. Setting enable_geoparquet_conversion = false does not help — the crash is in Parquet metadata parsing itself.

To Reproduce

INSTALL httpfs; LOAD httpfs;
INSTALL spatial; LOAD spatial;

-- This crashes in WASM but works in CLI v1.5.1
DESCRIBE SELECT * FROM read_parquet('https://s3.us-west-2.amazonaws.com/us-west-2.opendata.source.coop/walkthru-earth/opensensor-space/share/suitability_analysis_of_aq.parquet');

Error:

Invalid Error: stoi: no conversion
LINE 1: DESCRIBE SELECT * FROM read_parquet('https://s3.us-west-2.amazonaws.com/us-west...
                               ^

CLI comparison (works)

$ duckdb --version
v1.5.1 (Variegata) 7dbb2e646f

$ duckdb -c "INSTALL httpfs; LOAD httpfs; INSTALL spatial; LOAD spatial; DESCRIBE SELECT * FROM read_parquet('https://s3.us-west-2.amazonaws.com/us-west-2.opendata.source.coop/walkthru-earth/opensensor-space/share/suitability_analysis_of_aq.parquet');"

┌────────────────────────────────────────┐
│                Describe                │
│ name             varchar               │
│ type             varchar               │
│ priority         varchar               │
│ nearest_existing varchar               │
│ distance_km      double                │
│ source           varchar               │
│ geom             geometry('ogc:crs84') │
└────────────────────────────────────────┘

The file has a geometry('ogc:crs84') column. The WASM build seems to crash parsing the CRS metadata from the Parquet file.

Possibly related

• GeoArrow export #2187 (GeoArrow export — Unsupported type in DuckDB → Arrow Conversion: GEOMETRY) is a different issue about Arrow serialization. This bug crashes before any Arrow conversion happens.

Browser/Environment:

Firefox / Chrome (both)

Device:

MacBook Pro

DuckDB-Wasm Version:

1.33.1-dev40.0

DuckDB-Wasm Deployment:

Bundled (Vite + SvelteKit) — objex

[yharby]

Root cause investigation

Bisected across npm versions: 1.33.1-dev20.0 works, 1.33.1-dev34.0 is the first broken build. No versions were published between dev20 and dev34, so the break maps to the v1.5.0 core bump (commits c8036dd1..d2328895).

The crash path appears to be in the WASM Arrow export layer, specifically arrow_duck_schema.cpp which calls std::stoi(parameters) when serializing Arrow format strings. DuckDB v1.5 introduces parameterized GEOMETRY('ogc:crs84') types from GeoParquet CRS metadata. When the WASM Arrow bridge encounters this type, it attempts to parse the CRS string (e.g. ogc:crs84) as an integer, causing stoi: no conversion.

This is separate from #2187 (which is about json_typedef.cc explicitly throwing "unsupported type" for GEOMETRY). The stoi crash happens earlier in the Arrow C Data Interface export path.

Workaround for consumers: Pin to 1.33.1-dev20.0 (pre-v1.5 core, current latest tag). Setting enable_geoparquet_conversion = false does not help because the crash occurs at the read_parquet() level before any connection-level settings take effect.

Tested versions: dev19 ✓, dev20 ✓, dev31 ✗, dev34 ✗, dev40 ✗, dev41 ✗

cc @Maxxen (spatial extension)

[Maxxen]

The issue is unrelated to the read_parquet function or the CRS parsing - the problem is in the arrow_duck_schema.cpp where we look for the blob-fixed-size in the arrow c type string. We do a std::find, which probably gets confused when it finds the crs further down the blob after the :.

[yharby]

Based on @Maxxen's diagnosis, I traced the exact vulnerable code in duckdb/duckdb core (with help from my AI coding agent):

File: src/function/table/arrow/arrow_duck_schema.cpp

Two instances of the same bug pattern:

Line 190-192 (fixed-size binary w:NN):

} else if (format[0] == 'w') {
    string parameters = format.substr(format.find(':') + 1);
    auto fixed_size = NumericCast<idx_t>(std::stoi(parameters));

Line 229-231 (fixed-size list +w:NN):

} else if (format[0] == '+' && format[1] == 'w') {
    std::string parameters = format.substr(format.find(':') + 1);
    auto fixed_size = NumericCast<idx_t>(std::stoi(parameters));

format.find(':') scans the entire string for the first colon. The Arrow C Data Interface spec defines these formats as exactly w:NN (colon at position 1) and +w:NN (colon at position 2). But when the format string contains CRS metadata with : characters, find grabs the wrong colon, and std::stoi() receives non-numeric text.

Proposed fix — use fixed offsets per the Arrow spec instead of find(':'):

// Line 191: Arrow spec w:NN — colon is always at position 1
string parameters = format.substr(2);

// Line 230: Arrow spec +w:NN — colon is always at position 2
std::string parameters = format.substr(3);

Test file: https://s3.us-west-2.amazonaws.com/us-west-2.opendata.source.coop/walkthru-earth/opensensor-space/share/suitability_analysis_of_aq.parquet

Also confirmed that PR #2200 (dev41.0) does NOT fix this — tested with the above GeoParquet file: DESCRIBE, SELECT, and enable_geoparquet_conversion = false retry all still crash with stoi: no conversion.

@Maxxen — would this substr fix be the right approach? Happy to submit a PR to duckdb/duckdb if so.

[Maxxen]

Maybe? Have you verified that the fix solves the issue?

[yharby]

Hello @Maxxen and @carlopi, Can we have a new release based on the current merged solution for this issue ? Thank you so much !

[carlopi]

Hey @yharby, I'll cherry pick the fix and see if that works, we'll have that out likely tomorrow