Hi, We are using StarRocks tables built on Iceberg. The metadata and data are exported from GCP Bigquery to GCS bucket, then StarRocks tables can read the data. It worked well a while ago. But now I get the error message when querying StarRocks tables. Does anyone know what is the issue? (query works fine in Bigquery, but got this error in StarRocks)

I'd be happy to help! Please go ahead and share the question or provide more details about the issue you're facing.

The issue has been described in this thread. Please take a look at the beginning of this thread.

@Rocky - using StarRocks tables built on Iceberg. The metadata and data are exported from GCP Bigquery to GCS bucket, then StarRocks tables can read the data. It worked previously, now it shows Error 1064 (HY000) Getting analyzing error. Unknown proc node path: Snapshot for references SnapshotRef{} does not exist.

The error

Error 1064 (HY000) Getting analyzing error. Unknown proc node path: Snapshot for references SnapshotRef{} does not exist

indicates that StarRocks is encountering an inconsistency in the Iceberg metadata file (

metadata.json

) stored in your GCS bucket. Specifically, the "Snapshot for references" part of the error originates from the Iceberg library when a table reference (like the

main

branch) is defined but points to a snapshot ID that is missing from the table's snapshot history. Possible Causes 1. Stale Metadata Cache: StarRocks caches Iceberg metadata (like the snapshot ID and manifest locations) for performance. If you exported new data from BigQuery that updated or replaced the metadata in GCS, StarRocks might still be trying to use a cached snapshot ID that no longer exists in the new metadata file. 2. Inconsistent Export: The export process from BigQuery to GCS might have created a

metadata.json

where the

current-snapshot-id

or an entry in the

refs

map points to a snapshot ID that is not actually listed in the

snapshots

array. 3. Metadata Overwrite: If the export process overwrites the metadata file rather than appending to it, and StarRocks is mid-query or using a cached pointer, it will fail to find the expected snapshot. Recommended Troubleshooting Steps 1. Manually Refresh the Metadata Cache The most common fix for "worked previously, now fails" is to force StarRocks to re-read the metadata from GCS:

sql
-- Refresh a specific table
REFRESH EXTERNAL TABLE <catalog_name>.<database_name>.<table_name>;

-- Or refresh the entire catalog if multiple tables are affected
REFRESH CATALOG <catalog_name>;

2. Inspect the Iceberg Metadata Tables You can query StarRocks' internal metadata tables to see what it "sees" for the Iceberg table. If these queries fail with the same error, the issue is definitely in the

metadata.json

file itself.

sql
-- Check references (branches/tags)
SELECT * FROM <catalog>.<db>.<table>$refs;

-- Check available snapshots
SELECT * FROM <catalog>.<db>.<table>$snapshots;

Check if the

snapshot_id

in the

$refs

table exists in the

$snapshots

table. 3. Verify the

metadata.json

in GCS Locate the latest metadata JSON file in your GCS bucket (usually under

metadata/vN.metadata.json

). Open it and check: * Does

current-snapshot-id

match an entry in the

snapshots

list? * In the

refs

section, does

main

point to a valid

snapshot-id

? * If the table is empty (0 rows), ensure the export didn't leave a "broken" reference to a non-existent snapshot. 4. "Unknown proc node path" The

Unknown proc node path

part of the error is a side effect of the StarRocks Frontend (FE) failing to resolve the table schema during analysis because it couldn't parse the snapshot. If the refresh doesn't work, check your StarRocks FE logs (

fe.log

) for the full stack trace; it will often point to the exact Iceberg field it failed to parse. Note on StarRocks Version: If you are on an older version of StarRocks, you may be hitting a compatibility issue with newer Iceberg features (like branching/tagging) that BigQuery might be using. Ensure you are on a recent version (v3.1+) for the best Iceberg support. References • data_source/catalog/iceberg/iceberg_catalog.md • data_source/catalog/iceberg/iceberg_meta_table.md • faq/shared_data_faq.md • data_source/catalog/iceberg/procedures.md • administration/Meta_recovery.md

We found the reason of this issue. Currently the metadata json file generated by Bigquery command (version 2) does not meet the requirements of StarRocks, so StarRocks is not able to read the iceberg table. The version 1 metadata file generated by Bigqeury in the past did not have this issue. A ticket has been created for Google to investigate and fix the issue.