@Rocky - I am getting intermittent java.sql.SQLSyntaxErrorException: Build Exec OlapScanNode fail, scan info is invalid on StarRocks 3.5.10 running in shared data mode, when attempting to refresh an ASYNC materialized view built on top of HMS iceberg catalog. When it happens - the materialized view shows zero rows, even though the underlying query is extremely lightweight and simple. What am I facing?

The error

Build Exec OlapScanNode fail, scan info is invalid

in StarRocks shared-data mode (Cloud-native) typically indicates that the Frontend (FE) planner is unable to retrieve the metadata (tablet/shard locations) for the tablets it intends to scan. When this happens during an ASYNC Materialized View (MV) refresh built on an HMS Iceberg catalog, you are likely facing a transient metadata visibility issue or a race condition within the shared-data metadata management (StarOS). Why it happens 1. Metadata Visibility Lag: In shared-data mode, tablet metadata is managed by a separate service (StarOS/Lake). When an MV refreshes, it often creates new partitions or tablets via

INSERT OVERWRITE

. If the FE tries to build the execution plan for the refresh or a subsequent query before these new tablets are fully registered or visible in the metadata store, the "scan info" will be empty/invalid, causing the plan to fail. 2. Zero Rows Symptom: If the refresh task encounters this error during the planning phase of its internal

INSERT

statement, the task fails. If it happens during the "commit" phase or if a partial refresh logic is triggered that finds no valid data ranges due to metadata issues, the MV may end up with 0 rows or remain in its previous state. 3. Iceberg Metadata Staleness: Even with a simple query, StarRocks relies on its Iceberg metadata cache. There are known issues in the 3.5.x line (some fixed in 3.5.10, but some edge cases remain) where the Guava cache for Iceberg tables can become stale or the FE loses its

ConnectContext

when deploying scan ranges, leading to invalid scan info. Recommended Troubleshooting Steps Since you are on 3.5.10, you already have many recent fixes. To narrow this down: 1. Check FE Logs for Stack Traces: Search your

fe.log

and

fe.warn.log

for the string

Build Exec OlapScanNode fail

. Look for the underlying cause, which is often

Failed to get scan range

or

no queryable replica found

. In shared-data mode, this usually points to a failure in the

LakeScanNode

or communication with the StarOS service. 2. Verify Catalog Metadata Refresh: Ensure StarRocks is correctly perceiving changes in your HMS Iceberg catalog. You can try forcing a metadata refresh on the catalog before the MV refresh:

sql
    REFRESH EXTERNAL TABLE iceberg_catalog.db.table_name;

If this resolves the "zero rows" issue, the problem is likely the Iceberg metadata sync. 3. Check Tablet Health (Internal MV Storage): Even though the source is Iceberg, the MV storage itself is a StarRocks Lake table. Run:

sql
    SHOW PROC '/statistic';

Check if there are "Unhealthy Tablets." If there are, it confirms the metadata for the MV's internal storage is inconsistent. 4. Configuration Adjustments: Try increasing the following FE configurations if you suspect metadata sync delays: * `lake_autovacuum_grace_period_minutes`: Ensure it's high enough (default is usually 1 minute) so metadata for recently created versions isn't cleaned up too fast. * `catalog_metadata_cache_expiration_second`: Check if your Iceberg metadata is expiring too quickly. 5. Workaround: If the refresh is critical and the error is persistent for specific runs, try a manual refresh with a clean state:

sql
    REFRESH MATERIALIZED VIEW your_mv_name WITH FORCE;

Summary: You are likely hitting a race condition where the FE's view of the tablets (either the source Iceberg metadata or the target MV lake tablets) is out of sync with the actual storage metadata during the refresh task's execution. If the issue persists after a catalog refresh, it is likely a bug in the shared-data metadata publication phase, and providing the

fe.log

stack trace to the StarRocks community/support would be the next best step. References • release_notes/release-3.5.md