@Rocky I'm using StarRocks 4.0.9 in shared Data mode to read external iceebrg table which is created as part of AWS glue catalogue I'm able to read most of tables properly but some tables gives this error ERROR 1064 (HY000): Failed to execute metadata collection job. Property 'write.object-storage.path' has been deprecated and will be removed in 2.0, use 'write.data.path' instead. while it's write that old prperty is used but that was the case of other tables and that are working

The error you are seeing is a known issue caused by a strict validation in the Apache Iceberg Java library (which StarRocks uses to interface with Iceberg metadata). The property

write.object-storage.path

was used in older versions of Iceberg (and is often still injected by Amazon Athena or older Spark jobs) to define where data files should be stored. Newer versions of the Iceberg SDK have deprecated this in favor of

write.data.path

. While many tools still tolerate the old property, the specific version of the Iceberg SDK bundled with your StarRocks build (likely 3.3+ or your reported 4.0.9) is treating this deprecation warning as a hard failure during the Metadata Collection Job. Why it happens on some tables but not others: * Table Origin: Tables created via Amazon Athena or older EMR Spark scripts often have this property explicitly set in their metadata. Tables created via more recent Spark versions or StarRocks itself usually use the newer property or rely on the default path. * Metadata Refresh: StarRocks runs a background "metadata collection job" to cache Iceberg snapshots and statistics. If a table has this legacy property in its active metadata file, the Iceberg library fails to parse it, causing the collection job (and your query) to fail. ────────── How to Fix This The fix must be applied to the Iceberg table metadata itself using a tool that can modify the table properties (like Athena, Spark, or StarRocks if it allows the

ALTER

on the external table). Option 1: Fix via Amazon Athena (Recommended) Since your tables are in the AWS Glue Catalog, you can run these commands in the Athena console: 1. Remove the deprecated property:

sql
   ALTER TABLE <database_name>.<table_name> UNSET TBLPROPERTIES ('write.object-storage.path');

2. (Optional) Set the correct property: If you specifically need to define a custom data path (otherwise it defaults to the table location/data), use:

sql
   ALTER TABLE <database_name>.<table_name> SET TBLPROPERTIES ('write.data.path' = '<s3://your-bucket/your-table-path/data/>');

Option 2: Fix via Spark If you have access to a Spark shell connected to the same Glue Catalog:

scala
spark.sql("ALTER TABLE <catalog>.<db>.<table> UNSET TBLPROPERTIES ('write.object-storage.path')")

Option 3: Refresh StarRocks Metadata After fixing the table properties in Glue/Iceberg, you should force StarRocks to clear its cached (and failed) metadata:

sql
REFRESH EXTERNAL TABLE <catalog_name>.<db_name>.<table_name>;

Summary of properties Old Property (Deprecated) | New Property (Standard)

write.object-storage.path

|

write.data.path

write.folder-storage.path

|

write.data.path

By unsetting the old property, the Iceberg SDK will stop throwing the

IllegalArgumentException

, and StarRocks will be able to complete the metadata collection job successfully. References • data_source/catalog/iceberg/iceberg_catalog.md • sql-reference/System_variable.md • data_source/catalog/iceberg/iceberg_meta_table.md • administration/Meta_recovery.md • data_source/feature-support-data-lake-analytics.md

@Rocky but same peroperty is on another table which is working by same starrocks version 4.0.9 both are created by athena

The error you are encountering is caused by a strict validation in the Apache Iceberg SDK (version 1.5 and later), which is included in StarRocks 4.0.9. This SDK treats the deprecated property

write.object-storage.path

as a hard failure during certain metadata operations. Why it happens on some tables but not others If you see this property on "working" tables, it is likely because of one of the following reasons: 1. Metadata Collection Status: The error specifically mentions the "metadata collection job." This is a background task in StarRocks that gathers statistics for the Cost-Based Optimizer (CBO). It may not have run for your "working" tables yet, or those tables might be small enough that StarRocks hasn't triggered a full metadata scan that initializes the strict Iceberg

LocationProvider

. 2. Property Location: Athena often sets properties in two places: the AWS Glue Catalog (Metastore) and the actual Iceberg

metadata.json

file on S3. StarRocks reads the

metadata.json

for its core operations. It is possible the "working" tables only have the property in Glue, while the "failing" tables have it baked into the

metadata.json

file. 3. Iceberg Table Version: Tables created as Iceberg V2 (supporting row-level deletes) are often subject to stricter property validation by the newer Iceberg libraries than V1 tables. How to Fix You must remove the deprecated property from the table metadata. Since the tables were created by Athena in the AWS Glue Catalog, you can fix them using Athena or Spark. 1. Fix via Amazon Athena Run the following command for each failing table:

sql
-- Remove the deprecated property
ALTER TABLE <database>.<table_name> UNSET TBLPROPERTIES ('write.object-storage.path');

-- (Optional) Set the modern equivalent if you need custom data paths
ALTER TABLE <database>.<table_name> SET TBLPROPERTIES ('write.data.path' = '<s3://your-bucket/path/to/data/>');

2. Refresh StarRocks Metadata Once the property is removed in Glue/Athena, you should tell StarRocks to clear its cached metadata for that table:

sql
REFRESH EXTERNAL TABLE <catalog_name>.<database_name>.<table_name>;

Why this is happening now In older versions of Iceberg (pre-1.1.0),

write.object-storage.path

was required for high-performance S3 layouts. In current versions, this has been standardized to

write.data.path

. The Iceberg community decided to make this a breaking change for the upcoming 2.0 release, and recent library updates (like those in StarRocks 4.0) have begun enforcing this warning as an exception to force users to migrate. Rocky's Tip: If you have many tables, you can identify which ones have this property by checking the Iceberg metadata table directly in StarRocks:

sql
SELECT * FROM <catalog>.<db>.<table>$properties WHERE key = 'write.object-storage.path';

References • quick_start/iceberg.md • data_source/catalog/iceberg/iceberg_meta_table.md • data_source/catalog/iceberg/iceberg_catalog.md