[Bug][Iceberg] Querying HMS Iceberg View fails with NoSuchIcebergTableException (type=ICEBERG-VIEW) on 4.0.8

[2416210017]

Search before asking

• I had searched in the issues and found no similar issues.

Version

[Bug][Iceberg] Querying HMS Iceberg View fails with NoSuchIcebergTableException (type=ICEBERG-VIEW) on 4.0.8

What's Wrong?

Description

Querying an Iceberg View stored in Hive Metastore fails on Doris 4.0.8, even though:

• The catalog is a valid Iceberg HMS catalog
• enable_query_iceberg_views = true
• SHOW CREATE TABLE succeeds and returns the view DDL
• The underlying Iceberg tables referenced by the view can be queried

Doris recognizes the object as an external view during planning, but then loads it via loadTable / HiveTableOperations, which rejects type=ICEBERG-VIEW.

Environment

• Doris: doris-4.0.8-rc02-bc8ea1bac6d
• Catalog: Iceberg + HMS (type=iceberg, iceberg.catalog.type=hms)
• Metastore: Hive Metastore (SASL disabled / simple)
• Storage: Kerberos HDFS (HA)
• FE config: enable_query_iceberg_views = true

Catalog (sensitive values redacted):

CREATE CATALOG `linkhouse` PROPERTIES (
  "type" = "iceberg",
  "iceberg.catalog.type" = "hms",
  "warehouse" = "hdfs://<ns>/<warehouse>",
  "hive.metastore.uris" = "thrift://<hms-host>:32087",
  "hive.metastore.sasl.enabled" = "false",
  "hive.metastore.authentication.type" = "simple",
  "hdfs.authentication.type" = "kerberos",
  ...
);

What You Expected?

How to reproduce

1. Create an Iceberg HMS catalog as above.
2. In Spark/Iceberg, create an Iceberg View whose HMS table type is ICEBERG-VIEW, e.g. a UNION ALL of two Iceberg tables.
3. In Doris:

SHOW FRONTEND CONFIG LIKE '%enable_query_iceberg_views%';
-- Value = true

SHOW CREATE TABLE <catalog>.<db_view>.<view_name>;
-- succeeds, returns CREATE VIEW ... AS SELECT ... UNION ALL ...

SELECT * FROM <catalog>.<db_view>.<view_name> LIMIT 10;

Actual behavior

ERROR 1105 (HY000): errCode = 2, detailMessage = NoSuchIcebergTableException:
Not an iceberg table: <catalog>.<db>.<view> (type=ICEBERG-VIEW)

Sometimes the first attempt times out in Nereids while holding table locks:

Nereids cost too much time (186s > 30s)
plan time: {"lock_tables":186906, "analyze":-1, ...}

Then subsequent queries fail immediately with NoSuchIcebergTableException.

SHOW CREATE TABLE works and shows a normal Iceberg view definition (SELECT + UNION ALL over two Iceberg tables).

Expected behavior

With enable_query_iceberg_views=true and an HMS Iceberg catalog, SELECT on an Iceberg View should load view metadata via loadView / getIcebergView, expand the view SQL, and query the underlying tables — as documented for Iceberg views since 3.1.0.

Stack trace (FE)

java.lang.RuntimeException: NoSuchIcebergTableException:
Not an iceberg table: linkhouse.dc_stg_view.retail_gms_bill_delivery_return_dtl_ods (type=ICEBERG-VIEW)
    at org.apache.doris.datasource.iceberg.IcebergMetadataCache.loadTableCacheValue(IcebergMetadataCache.java:153)
    at org.apache.doris.datasource.iceberg.IcebergMetadataCache.getSnapshotCache(IcebergMetadataCache.java:113)
    at org.apache.doris.datasource.iceberg.IcebergUtils.getLatestSnapshotCacheValue(IcebergUtils.java:1551)
    at org.apache.doris.datasource.iceberg.IcebergUtils.getSnapshotCacheValue(IcebergUtils.java:1559)
    at org.apache.doris.datasource.iceberg.IcebergUtils.getIcebergSchema(IcebergUtils.java:1584)
    at org.apache.doris.datasource.iceberg.IcebergExternalTable.getFullSchema(IcebergExternalTable.java:258)
    at org.apache.doris.datasource.ExternalView.getFullSchema(ExternalView.java:71)
    at org.apache.doris.nereids.trees.plans.logical.LogicalView.computeOutput(LogicalView.java:122)
    ...
Caused by: org.apache.iceberg.exceptions.NoSuchIcebergTableException:
Not an iceberg table: ... (type=ICEBERG-VIEW)
    at org.apache.iceberg.hive.HiveOperationsBase.validateTableIsIceberg(HiveOperationsBase.java:103)
    at org.apache.iceberg.hive.HiveTableOperations.doRefresh(HiveTableOperations.java:108)
    at org.apache.iceberg.hive.HiveCatalog.loadTable(...)
    at org.apache.doris.datasource.iceberg.IcebergMetadataOps.loadTable(IcebergMetadataOps.java:1111)

Analysis

Planning already treats the object as an ExternalView (LogicalView.computeOutput → ExternalView.getFullSchema).

When computing the view output schema, Doris still calls:

IcebergExternalTable.getFullSchema → IcebergUtils.getIcebergSchema → snapshot cache / loadTable

HMS reports type=ICEBERG-VIEW, so HiveTableOperations.validateTableIsIceberg throws NoSuchIcebergTableException.

The view path should use loadView / getIcebergView (and view schema), not table snapshot loading.

This looks like a regression or incomplete wiring of #51376 (support iceberg view query) on the Nereids schema path in 4.0.8.

Workaround

Do not query the Iceberg View in Doris. Query the two base Iceberg tables (or create a Doris-side VIEW over them). Base table SELECT works.

Additional notes

Unrelated FE warning (Ranger policy refresh 401) appears in logs but is not the cause of ICEBERG-VIEW / loadTable.

Happy to provide a minimal Spark DDL for the view if needed.

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[Doris-Breakwater]

Breakwater-GitHub-Analysis-Slot: slot_3a49784340ff

Initial assessment

Confirmed FE bug / implementation gap in doris-4.0.8-rc02-bc8ea1bac6d (high confidence). The supplied stack trace matches the source at the exact reported commit. This issue currently has no labels; area/iceberg is the most direct existing project label, with area/catalog also applicable.

Verified code path

1. Nereids correctly identifies the object as an Iceberg view in BindRelation, obtains its SQL through getViewText()/loadView, and wraps it in ExternalView + LogicalView.
2. While deriving the view output, LogicalView.computeOutput() asks the wrapper for getFullSchema(). ExternalView.getFullSchema() delegates to the underlying IcebergExternalTable.
3. IcebergExternalTable.getFullSchema() unconditionally calls IcebergUtils.getIcebergSchema(this). That method obtains a snapshot first, which enters IcebergMetadataCache.getSnapshotCache() and its table cache; a cache miss calls IcebergMetadataOps.loadTable(). HMS then correctly rejects the ICEBERG-VIEW object as not being an Iceberg table.
4. A view-aware schema path already exists: IcebergExternalTable.initSchema() passes isView, and IcebergUtils.loadViewSchemaCacheValue() loads view.schema(). The getFullSchema() override bypasses that path.
5. SHOW CREATE TABLE succeeds for the same reason described in the report: its view branch calls showCreateView() -> getViewText() -> getIcebergView(), without entering the table snapshot cache.

This is more accurately described as incomplete wiring in the original Iceberg-view support than as a demonstrated 4.0.8 regression. The existing HMS Iceberg-view regression suite is unconditionally disabled with if (true), so the failing SELECT path has no active coverage. Source history also shows the LogicalView schema access predates the Iceberg-view feature.

The Kerberos/HDFS and Ranger warnings are not on the exception path shown above. No evidence currently links them to the NoSuchIcebergTableException.

About the 186-second lock_tables value

This value alone does not prove that table locks were held for 186 seconds. In this version, collectAndLockTable() records the phase end only after both relation collection and statementContext.lock(), and Nereids Lock Table Time is measured from parse completion to that shared endpoint. Slow catalog initialization/metadata lookup during collection and actual lock acquisition are therefore aggregated. The timeout may be related metadata warm-up, lock contention, or both; the current evidence cannot distinguish them.

To establish the timeout cause, please provide:

• the query ID and complete FE log interval from query receipt through timeout;
• one or more FE thread dumps captured while the query is stalled;
• the full planning profile/timing JSON, plus any concurrent refresh/DDL activity involving the referenced tables;
• the minimal Spark Iceberg view DDL and Spark/Iceberg version (also useful for an enabled regression test).

These items are not required to confirm the main schema-loading bug; they are needed only to prove the separate long-planning cause.

Recommended next steps

1. Add an enabled HMS Iceberg-view regression covering SELECT, DESCRIBE, and SHOW CREATE, including the reported UNION ALL shape. Assert that querying a view never invokes the Iceberg table/snapshot loader.
2. In the legacy Iceberg table implementation, make getFullSchema() select the existing view-schema cache/load path for isView(), while preserving the current snapshot-aware schema path for real tables. A narrow implementation can use the existing IcebergSchemaCacheKey/NEWEST_SCHEMA_ID view-aware loader rather than duplicating Iceberg schema conversion.
3. Verify that ordinary table queries and table time travel remain unchanged, and test view schema aliases/types against the analyzed child output.
4. Audit maintained legacy branches: current branch-4.0, branch-4.1, and branch-4.2 source all still contain an unconditional table-snapshot schema path for IcebergExternalTable.getFullSchema(). The plugin-driven master path already obtains view columns from getViewDefinition(), but it should still receive an end-to-end HMS view test.

The documented workaround - querying the base Iceberg tables or using a Doris-side view - is appropriate until a fixed build is available.