Summary
The DuckLake catalog-version preflight in packages/server/src/ducklake_version.ts only accepts the 0.3-line catalog format (["0.1", "0.2", "0.3-dev1", "0.3"], with a comment stating it is "paired with [email protected]"). However, the engine the server actually runs — @duckdb/node-api pulled in via @malloydata/db-duckdb — has since moved to DuckDB 1.5.x, whose DuckLake extension reads and writes the DuckLake 1.0 catalog format (recorded as version = "1.0").
As a result, the preflight rejects the very catalogs the bundled extension produces, surfacing a non-retryable 422 ("DuckLake catalog version 1.0 is newer than this Publisher's extension supports") even though the extension can read the catalog fine. This blocks attaching DuckLake catalogs across connections and the materialization store.
Reproduction / evidence
Running the repo's current engine directly:
duckdb version: v1.5.3 (Variegata)
ducklake extension: installed (REPOSITORY), version e6a3bd0a
fresh catalog __ducklake_metadata_*.ducklake_metadata -> key=version, value="1.0"
The preflight compares that raw "1.0" string against SUPPORTED_CATALOG_VERSIONS with an exact .includes() match (StorageManager.readDuckLakeCatalogVersion → isCatalogVersionSupported), so a 1.0 catalog never matches and is rejected.
The header comment in ducklake_version.ts already anticipated this: "When the Publisher upgrades to the DuckLake 1.0 line (separate PR, requires [email protected]+), extend this list to include 1.0 and later format versions." The engine upgrade landed, but the list wasn't extended.
Context
Proposed fix
- Update
SUPPORTED_CATALOG_VERSIONS to the 1.0 line (["1.0"]) and refresh the surrounding comment (it still references [email protected] / the 0.3 line).
- Update
ducklake_version.spec.ts, which currently asserts the old list and that "1.0" is rejected.
Open question
Existing 0.3-format catalogs (created under DuckDB 1.4.x) won't attach under 1.5.x without migration. Should Publisher (a) keep failing fast with a clear 422 and require an out-of-band migration (e.g. a one-time attach with AUTOMATIC_MIGRATION true), or (b) add AUTOMATIC_MIGRATION true to its ATTACH path? Option (a) is non-destructive and is the conservative default; (b) silently mutates the catalog on attach.
Summary
The DuckLake catalog-version preflight in
packages/server/src/ducklake_version.tsonly accepts the 0.3-line catalog format (["0.1", "0.2", "0.3-dev1", "0.3"], with a comment stating it is "paired with [email protected]"). However, the engine the server actually runs —@duckdb/node-apipulled in via@malloydata/db-duckdb— has since moved to DuckDB 1.5.x, whose DuckLake extension reads and writes the DuckLake 1.0 catalog format (recorded asversion = "1.0").As a result, the preflight rejects the very catalogs the bundled extension produces, surfacing a non-retryable 422 ("DuckLake catalog version 1.0 is newer than this Publisher's extension supports") even though the extension can read the catalog fine. This blocks attaching DuckLake catalogs across connections and the materialization store.
Reproduction / evidence
Running the repo's current engine directly:
The preflight compares that raw
"1.0"string againstSUPPORTED_CATALOG_VERSIONSwith an exact.includes()match (StorageManager.readDuckLakeCatalogVersion→isCatalogVersionSupported), so a 1.0 catalog never matches and is rejected.The header comment in
ducklake_version.tsalready anticipated this: "When the Publisher upgrades to the DuckLake 1.0 line (separate PR, requires [email protected]+), extend this list to include 1.0 and later format versions." The engine upgrade landed, but the list wasn't extended.Context
Proposed fix
SUPPORTED_CATALOG_VERSIONSto the 1.0 line (["1.0"]) and refresh the surrounding comment (it still references [email protected] / the 0.3 line).ducklake_version.spec.ts, which currently asserts the old list and that"1.0"is rejected.Open question
Existing 0.3-format catalogs (created under DuckDB 1.4.x) won't attach under 1.5.x without migration. Should Publisher (a) keep failing fast with a clear 422 and require an out-of-band migration (e.g. a one-time attach with
AUTOMATIC_MIGRATION true), or (b) addAUTOMATIC_MIGRATION trueto its ATTACH path? Option (a) is non-destructive and is the conservative default; (b) silently mutates the catalog on attach.