[v2 Bug] DuckDB: incremental on_schema_change column probe panics on BLOB columns (BinaryView is not supported), exits 0

[jelder]

Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

• I believe this is a new bug in dbt v2.x
• I have searched the existing issues and could not find a duplicate

Current Behavior

With the DuckDB adapter, an incremental model that selects a BLOB column succeeds on its first run (plain CTAS) and then panics on every subsequent run:

panic: panicked at fs/sa/crates/dbt-adapter/src/column/column_builder.rs:499:22:
called `Result::unwrap()` on an `Err` value: AdapterError { kind: NotSupported, message: "Failed to convert type BinaryView. Error: BinaryView is not supported for DuckDB", sqlstate: [48, 48, 48, 48, 48], vendor_code: None, source: None }

The trigger is the on_schema_change column probe (select ... from (<model sql>) as __dbt_sbq where false limit 0). The empty result's Arrow schema carries the BLOB column as BinaryView, which the DuckDB column type mapper does not handle, and the unwrap() turns that into a panic.

Two things make this worse than a normal error:

• The process exits 0 after the panic, so orchestrators do not notice the failed run.
• It affects delete+insert and microbatch alike (any strategy that runs the probe).

What still works, for triangulation:

• on_schema_change='ignore' (no probe) → run succeeds.
• Same model with payload::varchar as payload → run succeeds, so the BLOB type is the trigger.
• adapter.get_columns_in_relation() on a table with a BLOB column → fine (catalog path, not Arrow).
• dbt show --inline "select '\x01'::blob as b" → fine.
• Profile settings: arrow_output_version: '1.0' → no effect on the panic.

Expected Behavior

BLOB columns should map to a dbt column type (DuckDB's BLOB) whether the driver hands them back as Arrow Binary, LargeBinary, or BinaryView. At minimum, an unsupported type should surface as a model error with a non-zero exit code rather than a panic that exits 0.

Steps To Reproduce

Three-file project, no packages:

dbt_project.yml

name: blob_mre
version: "1.0.0"
profile: blob_mre
model-paths: ["models"]
flags:
  send_anonymous_usage_stats: false
on-run-start:
  - "create table if not exists src (id integer, payload blob)"

profiles.yml

blob_mre:
  target: dev
  outputs:
    dev:
      type: duckdb
      path: mre.duckdb
      threads: 1

models/incr.sql

{{ config(
    materialized='incremental',
    incremental_strategy='delete+insert',
    unique_key='id',
    on_schema_change='append_new_columns'
) }}
select id, payload from src

pip install dbt==2.0.5
dbt run --profiles-dir .   # 1st run: CTAS, succeeds
dbt run --profiles-dir .   # 2nd run: panics, exit code 0

Relevant log output

$ dbt run --profiles-dir .
       dbt 2.0.5
   Loading profiles.yml
  Finished [  0.00s] hook  blob_mre-on-run-start-0
panic: panicked at fs/sa/crates/dbt-adapter/src/column/column_builder.rs:499:22:
called `Result::unwrap()` on an `Err` value: AdapterError { kind: NotSupported, message: "Failed to convert type BinaryView. Error: BinaryView is not supported for DuckDB", sqlstate: [48, 48, 48, 48, 48], vendor_code: None, source: None }
$ echo $?
0

Last statement in logs/query_log.sql before the panic:

select * from (
    select id, payload from src
) as __dbt_sbq
where false
limit 0
;

Environment

• OS: macOS 15 (Darwin 25.6.0)
• CPU: ARM (Apple Silicon)
• dbt distribution and version: dbt 2.0.5 from PyPI (pip install dbt==2.0.5); bundled DuckDB reports v1.5.5 via select version()

Which database adapter are you using?

duckdb

Is this a discrepancy vs. dbt 1.x?

• Yes — this works in dbt 1.x but not in dbt v2.x

The same models run daily on dbt-core 1.11.10 + dbt-duckdb 1.10.1 against MotherDuck.

Additional Context

Found while evaluating a v2 migration of a project whose fact table has three BLOB columns (16-byte UUID keys and fingerprints), so every incremental model in the project hits this on its second run. Happy to test a fix or a nightly build.