[Bug] DuckDB endpoint_type is validated but never emitted into ATTACH, breaking Glue and S3 Tables #15725

Rewritten 2026-07-29. The first version of this issue was written against a stale checkout and framed the problem as Glue-specific auth defaulting. Re-verified against main: the actual defect is broader and simpler — endpoint_type is accepted by the schema and then silently discarded. That breaks both Glue and S3 Tables.

Summary

config.duckdb.endpoint_type (GLUE | S3_TABLES) is fully validated by the catalogs.yml v2 schema but is never emitted into the ATTACH statement. A user's catalog configuration is accepted and then dropped, producing an ATTACH that cannot connect to the intended catalog.

Evidence

The schema validates it. crates/dbt-schemas/src/schemas/dbt_catalogs_v2.rs:

• const DUCKDB_ENDPOINT_TYPES: &[&str] = &["GLUE", "S3_TABLES"];
• endpoint and endpoint_type are mutually exclusive, and exactly one is required
• endpoint_type: S3_TABLES additionally requires warehouse
• authorization_type cannot be combined with endpoint_type

The attach builder never emits it. build_duckdb_catalog_attach_stmt in crates/dbt-adapter/src/engine/duckdb_attach.rs emits ENDPOINT when endpoint is set, and there is no ENDPOINT_TYPE branch anywhere in the crate — git grep ENDPOINT_TYPE over crates/**/*.rs returns only the schema and an unrelated dbt-auth BigQuery constant.

Net effect for the documented Glue shortcut. Configuring endpoint_type: GLUE:

1. passes validation,
2. forbids you from setting authorization_type yourself,
3. produces an ATTACH with no ENDPOINT, no ENDPOINT_TYPE, and no AUTHORIZATION_TYPE.

DuckDB then falls back to its own defaults (oauth2), which is wrong for Glue. The schema actively prevents the user from working around it.

This is a regression

ENDPOINT_TYPE emission was added by #9727 and removed when the part 1 catalogs stack landed (dfe9a517c), while the schema-side validation was kept. The Glue attach fixtures (glue_minimal, glue_with_secret_and_endpoint_type, multi_catalog_glue_plus_iceberg_rest) were deleted in the same change — there is no Glue fixture anywhere on main today, which is why no test caught it.

catalog_attach_defaults presets write-compat options for Horizon and Unity only (_ => &[]), so Glue also receives no AUTHORIZATION_TYPE 'SIGV4' default.

Secondary: endpoint scheme handling

endpoint is interpolated verbatim:

opts.push(format!("ENDPOINT '{}'", escape_string_literal(ep, AdapterType::DuckDB)));

DuckDB's iceberg extension prepends its own scheme, so a value written as a "full URL" (https://glue.us-east-1.amazonaws.com/iceberg) yields https://https://…. The field's own doc string says "Full REST catalog URL", so docs and behavior disagree. Either normalize the scheme or document a bare host.

Fix

• Emit ENDPOINT_TYPE '<value>' when endpoint_type is set
• Give Glue a catalog_attach_defaults entry with AUTHORIZATION_TYPE 'SIGV4' (and confirm what S3_TABLES needs — SigV4 with the s3tables signing name)
• Restore Glue attach fixtures, and add an endpoint_type: S3_TABLES fixture, so emission is snapshot-tested — validation-only tests did not catch this
• Normalize or document endpoint scheme handling
• Re-check whether the authorization_type × endpoint_type exclusivity rule is still the contract we want once emission works

Currently-working configuration

Sidesteps endpoint_type entirely:

catalogs:
  - name: glue_cld
    type: iceberg_rest
    table_format: iceberg
    config:
      duckdb:
        endpoint: "glue.{{ env_var('AWS_REGION', 'us-east-1') }}.amazonaws.com/iceberg"  # NO scheme
        warehouse: "{{ env_var('DBT_GLUE_CATALOG_ID') }}"   # AWS account id == Glue catalog id
        authorization_type: SIGV4
        secret: glue_s3

Blocks

• Support Amazon S3 Tables catalog (DuckDB Iceberg REST) #15267 — Amazon S3 Tables cannot attach until endpoint_type is emitted
• AWS Glue Iceberg REST catalog: full DuckDB write support #15268 — AWS Glue writes; Glue cannot attach at all today, so reads must be fixed first

Parent: #15265