Service   dbt Lake Compute (private beta), dbt Fusion 2.0.6, adapter `lakecompute`,
          method `fivetran`
Lake      Fivetran MDLS "sap_cds_dbt" (Fivetran id obeisance_plaintive), Apache
          Iceberg on Google Cloud Storage, GCP us-east4, Polaris 1.7.0
Namespace s4hana_otc_saphanadb (78 tables, written by Fivetran connector
          amniotic_protectorate, source SAP S/4HANA)
Date      2026-10-27

SYMPTOM
Lake Compute cannot load exactly one table in that namespace: `kna1`. Every other
table in the same namespace loads and queries normally -- a 102-model dbt project
built 94 models against ~21 of them in 3m21s on the same token, same session.

MINIMAL REPRODUCER
  dbt show --adapter lakecompute \
    --inline "select count(*) as n from obeisance_plaintive.s4hana_otc_saphanadb.kna1"

ERROR (identical on every attempt, 4 attempts over ~30 minutes)
  HTTP 503: query analysis unavailable, retry:
  {"detail":"MDLS catalog 'obeisance_plaintive' failed to load
   obeisance_plaintive.s4hana_otc_saphanadb.kna1: (400) ...
   error=ErrorModel(message='Cannot set metadata location with changes to table
   metadata: 1 changes', type='IllegalArgumentException', code=400)"}

  Polaris x-request-id: 8512efdc-97cd-4a2a-b52f-81b0a919efcf
                        07f81219-4e68-4bfc-b86f-c6545ed2b0b4

THE TABLE IS HEALTHY -- IT IS THE LOAD PATH
DuckDB 1.5.3, ATTACHed to the SAME Polaris catalog with the SAME principal,
reads it without complaint:
  select count(*) from lake.s4hana_otc_saphanadb.kna1   ->  201 rows

Table metadata, next to a table that loads fine (vbak):
  kna1   format-version 2, 2 schemas, 1 partition spec, 1 sort order,
         2 snapshots, metadata-log 3, 267 columns
  vbak   format-version 2, 2 schemas, 1 partition spec, 1 sort order,
        12 snapshots, metadata-log 3, 228 columns
  Both carry identical properties, incl. fivetran.managed-by=mdls,
  write.format.default=parquet, write.metadata.previous-versions-max=3.
  metadata-location:
  gs://sap_cds_dbt/sap_cds_views/s4hana_otc_saphanadb/kna1/metadata/
    00004-8b55fd50-e91c-467c-b0de-09fe8872ee96.metadata.json

The only notable difference is width: 267 columns vs 228.

NOT STALE METADATA
A full connector re-sync (succeeded_at 2026-10-27T21:02:58Z) did not change the
behaviour -- the failure is byte-identical before and after.

IMPACT
9 dbt models skipped, including two of the seven cards of our S/4HANA Sales
Management Overview demo (Incoming Orders, Customer Returns).

WORKAROUNDS ATTEMPTED, ALL BLOCKED
  - DuckDB write of a copy into the Lake Compute namespace:
      IO Error: Failed to create directory "data": Permission denied
  - Polaris register of the same metadata.json under a new table name:
      403 -- principal customer_obeisance_plaintive_user not authorized for
      op REGISTER_TABLE
  - iceberg_scan() of the metadata path from inside Lake Compute:
      "Authentication Failure - GCS authentication failed. No credentials
      provided." (worker holds only Polaris-vended per-table credentials)

ASK
Is the 400 raised because the catalog-load path sends a metadata-location update
together with another metadata change in one commit? If so, is there a table
attribute on our side that triggers it, or is it a service-side fix?