<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Google Cloud Lakehouse catalog federation (Beta): queries fail with &amp;quot;Unrecognized....&amp;quot; in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/google-cloud-lakehouse-catalog-federation-beta-queries-fail-with/m-p/165086#M55388</link>
    <description>&lt;P&gt;Hey matko,&lt;/P&gt;&lt;P&gt;Short version: your diagnosis looks right, and this reads like a Beta rollout gap rather than anything you misconfigured.&lt;/P&gt;&lt;P&gt;The stack trace (toProto failing in loadForeignSecurableMetadataAndUpdateCache on an unrecognized securable kind) plus your test matrix — same error on Current and Preview channels, serverless client envs 3 and 4, and two high-privilege principals — pretty cleanly rules out permissions/config and points to exactly what you said: the control plane emits TABLE_FOREIGN_GOOGLE_CLOUD_LAKEHOUSE but the engine build doesn't have it in its enum yet. Classic control-plane-ahead-of-data-plane skew on a young Beta (the GCP Lakehouse catalog federation feature only landed around April 2026).&lt;/P&gt;&lt;P&gt;The catch: you're serverless-only, so you can't pin a newer DBR to get ahead of it. The enum support has to ship in Databricks' serverless image for your region. So the useful question to put to them is very specific: is TABLE_FOREIGN_GOOGLE_CLOUD_LAKEHOUSE rolled to us-central1 serverless yet, and in which client version? Regional staged rollout would explain why CREATE CONNECTION / the foreign catalog succeed while every query fails.&lt;/P&gt;&lt;P&gt;On the HMS-federation Iceberg "does not support batch scan" — I'd resist calling it the same bug (different federation path), but it rhymes: metadata registers fine, the read path refuses, and a plain Parquet table over the same federation reads fine. Feels like the federated read path not wiring up Iceberg scans yet on that route. That's inference, not documented.&lt;/P&gt;&lt;P&gt;What I'd do: take both to Databricks through an actual support case / your account team (and the Preview program contact if you have one), not the forum — these are Beta features only their engineering can confirm or fix. Hand them exactly what you posted here; it's a clean, well-isolated repro and will save a round trip.&lt;/P&gt;&lt;P&gt;If you just need reads unblocked now, might be worth testing whether you can reach the same GCS Iceberg tables through a route that doesn't depend on this securable kind (e.g. the UC Iceberg REST Catalog path) — flagging that as "worth trying," not confirmed for this connector&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 07 Aug 2026 11:13:41 GMT</pubDate>
    <dc:creator>ThomazNeto</dc:creator>
    <dc:date>2026-08-07T11:13:41Z</dc:date>
    <item>
      <title>Google Cloud Lakehouse catalog federation (Beta): queries fail with "Unrecognized...."</title>
      <link>https://community.databricks.com/t5/data-engineering/google-cloud-lakehouse-catalog-federation-beta-queries-fail-with/m-p/164707#M55320</link>
      <description>&lt;P&gt;Has anyone gotten the new **Google Cloud Lakehouse catalog federation** Beta (GCP workspaces) to actually run queries?&lt;/P&gt;&lt;P&gt;Setup (followed the docs end to end):&lt;BR /&gt;- GCP workspace (us-central1, serverless-only), Unity Catalog&lt;BR /&gt;- Previews page: Google Cloud Lakehouse federation toggle ON&lt;BR /&gt;- `CREATE CONNECTION ... TYPE GOOGLE_CLOUD_LAKEHOUSE` with a service-account JSON — created fine&lt;BR /&gt;- Foreign catalog over it (`warehouse 'bq://projects/&amp;lt;project&amp;gt;'`, authorized paths, storage root) — created fine&lt;BR /&gt;- All IAM sorted: the earlier, well-formed permission errors (BigQuery metadata read, GCS object read) appeared and were fixed with grants — so the control-plane path provably reaches our Iceberg metadata in GCS&lt;/P&gt;&lt;P&gt;**The problem — every query, on every engine:**&lt;/P&gt;&lt;P&gt;```&lt;BR /&gt;Unrecognized securable kind TABLE_FOREIGN_GOOGLE_CLOUD_LAKEHOUSE&lt;BR /&gt;java.lang.IllegalArgumentException&lt;BR /&gt;at com.databricks.sql.managedcatalog.client.TypeConversionUtils.toProto(TypeConversionUtils.scala:1960)&lt;BR /&gt;at com.databricks.sql.managedcatalog.client.ManagedCatalogClientImpl.updateMetadataSnapshot(...)&lt;BR /&gt;at com.databricks.sql.managedcatalog.PermissionEnforcingManagedCatalog.loadForeignSecurableMetadataAndUpdateCache(...)&lt;BR /&gt;```&lt;/P&gt;&lt;P&gt;Reproduced identically on:&lt;BR /&gt;- DBSQL Serverless — Current channel&lt;BR /&gt;- DBSQL Serverless — Preview channel (warehouse restarted after enabling the preview)&lt;BR /&gt;- Serverless notebooks/jobs — default environment, and environment client versions 3 and 4&lt;BR /&gt;- Two different principals (catalog-owner service principal, and a workspace admin with ALL PRIVILEGES + MANAGE) — same error, so not permissions&lt;/P&gt;&lt;P&gt;It looks like the engines' catalog client simply doesn't have the new securable kind in its enum yet (control plane speaks it, engines don't).&lt;/P&gt;&lt;P&gt;Questions:&lt;BR /&gt;1. Has anyone successfully queried a `GOOGLE_CLOUD_LAKEHOUSE` foreign catalog? On which engine/version?&lt;BR /&gt;2. Is there a known engine version / rollout timeline for `TABLE_FOREIGN_GOOGLE_CLOUD_LAKEHOUSE` support?&lt;BR /&gt;3. Possibly related: on the same workspace, Iceberg tables via **external HMS federation** fail with `Table 'browse_only_table' does not support batch scan` (while an identically-federated plain parquet table reads fine) — same story of an Iceberg-federation preview that the docs describe but the engines refuse. If you've hit either of these and got past them, how?&lt;/P&gt;&lt;P&gt;Any data points appreciated — happy to share more repro details.&lt;/P&gt;</description>
      <pubDate>Mon, 03 Aug 2026 07:46:15 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/google-cloud-lakehouse-catalog-federation-beta-queries-fail-with/m-p/164707#M55320</guid>
      <dc:creator>matko</dc:creator>
      <dc:date>2026-08-03T07:46:15Z</dc:date>
    </item>
    <item>
      <title>Re: Google Cloud Lakehouse catalog federation (Beta): queries fail with "Unrecognized...."</title>
      <link>https://community.databricks.com/t5/data-engineering/google-cloud-lakehouse-catalog-federation-beta-queries-fail-with/m-p/165086#M55388</link>
      <description>&lt;P&gt;Hey matko,&lt;/P&gt;&lt;P&gt;Short version: your diagnosis looks right, and this reads like a Beta rollout gap rather than anything you misconfigured.&lt;/P&gt;&lt;P&gt;The stack trace (toProto failing in loadForeignSecurableMetadataAndUpdateCache on an unrecognized securable kind) plus your test matrix — same error on Current and Preview channels, serverless client envs 3 and 4, and two high-privilege principals — pretty cleanly rules out permissions/config and points to exactly what you said: the control plane emits TABLE_FOREIGN_GOOGLE_CLOUD_LAKEHOUSE but the engine build doesn't have it in its enum yet. Classic control-plane-ahead-of-data-plane skew on a young Beta (the GCP Lakehouse catalog federation feature only landed around April 2026).&lt;/P&gt;&lt;P&gt;The catch: you're serverless-only, so you can't pin a newer DBR to get ahead of it. The enum support has to ship in Databricks' serverless image for your region. So the useful question to put to them is very specific: is TABLE_FOREIGN_GOOGLE_CLOUD_LAKEHOUSE rolled to us-central1 serverless yet, and in which client version? Regional staged rollout would explain why CREATE CONNECTION / the foreign catalog succeed while every query fails.&lt;/P&gt;&lt;P&gt;On the HMS-federation Iceberg "does not support batch scan" — I'd resist calling it the same bug (different federation path), but it rhymes: metadata registers fine, the read path refuses, and a plain Parquet table over the same federation reads fine. Feels like the federated read path not wiring up Iceberg scans yet on that route. That's inference, not documented.&lt;/P&gt;&lt;P&gt;What I'd do: take both to Databricks through an actual support case / your account team (and the Preview program contact if you have one), not the forum — these are Beta features only their engineering can confirm or fix. Hand them exactly what you posted here; it's a clean, well-isolated repro and will save a round trip.&lt;/P&gt;&lt;P&gt;If you just need reads unblocked now, might be worth testing whether you can reach the same GCS Iceberg tables through a route that doesn't depend on this securable kind (e.g. the UC Iceberg REST Catalog path) — flagging that as "worth trying," not confirmed for this connector&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 07 Aug 2026 11:13:41 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/google-cloud-lakehouse-catalog-federation-beta-queries-fail-with/m-p/165086#M55388</guid>
      <dc:creator>ThomazNeto</dc:creator>
      <dc:date>2026-08-07T11:13:41Z</dc:date>
    </item>
  </channel>
</rss>

