@Rocky im receiving this error with an s3 table bucket iceberg catalog:

2026-06-24 00:38:16.332Z ERROR (starrocks-mysql-nio-pool-38797|578211) [IcebergConnectorScanRangeSource.toScanRanges():290] build scan range failed
 java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266)
	at java.base/java.util.Objects.checkIndex(Objects.java:361)
	at java.base/java.util.ArrayList.get(ArrayList.java:427)
	at com.starrocks.connector.iceberg.IcebergConnectorScanRangeSource.getCurBucketId(IcebergConnectorScanRangeSource.java:459)
	at com.starrocks.connector.iceberg.IcebergConnectorScanRangeSource.extractBucketId(IcebergConnectorScanRangeSource.java:471)
	at com.starrocks.connector.iceberg.IcebergConnectorScanRangeSource.buildScanRange(IcebergConnectorScanRangeSource.java:418)
	at com.starrocks.connector.iceberg.IcebergConnectorScanRangeSource.buildScanRanges(IcebergConnectorScanRangeSource.java:296)
	at com.starrocks.connector.iceberg.IcebergConnectorScanRangeSource.toScanRanges(IcebergConnectorScanRangeSource.java:283)
	at com.starrocks.connector.iceberg.IcebergConnectorScanRangeSource.getSourceOutputs(IcebergConnectorScanRangeSource.java:211)
	at com.starrocks.connector.ConnectorScanRangeSource.getOutputs(ConnectorScanRangeSource.java:27)
	at com.starrocks.planner.IcebergScanNode.getScanRangeLocations(IcebergScanNode.java:131)
	at com.starrocks.qe.scheduler.assignment.BackendSelectorFactory.create(BackendSelectorFactory.java:58)
	at com.starrocks.qe.scheduler.assignment.LocalFragmentAssignmentStrategy.assignScanRangesToWorker(LocalFragmentAssignmentStrategy.java:102)
	at com.starrocks.qe.scheduler.assignment.LocalFragmentAssignmentStrategy.assignFragmentToWorker(LocalFragmentAssignmentStrategy.java:76)
	at com.starrocks.qe.CoordinatorPreprocessor.computeFragmentInstances(CoordinatorPreprocessor.java:271)
	at com.starrocks.qe.CoordinatorPreprocessor.prepareExec(CoordinatorPreprocessor.java:227)
	at com.starrocks.qe.DefaultCoordinator.prepareExec(DefaultCoordinator.java:515)
	at com.starrocks.qe.DefaultCoordinator.startScheduling(DefaultCoordinator.java:577)
	at com.starrocks.qe.scheduler.Coordinator.execWithQueryDeployExecutor(Coordinator.java:108)
	at com.starrocks.qe.StmtExecutor.handleQueryStmt(StmtExecutor.java:1876)
	at com.starrocks.qe.StmtExecutor.execute(StmtExecutor.java:1069)
	at com.starrocks.qe.ConnectProcessor.executeQueryAttempt(ConnectProcessor.java:600)
	at com.starrocks.qe.ConnectProcessor.runWithParserStageRetry(ConnectProcessor.java:494)
	at com.starrocks.qe.ConnectProcessor.handleQuery(ConnectProcessor.java:431)
	at com.starrocks.qe.ConnectProcessor.dispatch(ConnectProcessor.java:831)
	at com.starrocks.qe.ConnectProcessor.processOnce(ConnectProcessor.java:1216)
	at com.starrocks.mysql.nio.MySQLReadListener.handleRequest(MySQLReadListener.java:152)
	at com.starrocks.mysql.nio.MySQLReadListener.lambda$handleEvent$0(MySQLReadListener.java:92)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:840)

References • quick_start/iceberg.md • unloading/Spark_connector.md

@Rocky all of my other queries are working except this. the docs you provided are not related

The error

java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0

occurring in

IcebergConnectorScanRangeSource.getCurBucketId

typically indicates a bug in how StarRocks handles Iceberg bucket partitions or partition spec evolution. Why this is happening The stack trace shows that during the query planning phase, StarRocks is attempting to extract a Bucket ID from an Iceberg data file's partition values. This is part of StarRocks' optimization to support bucket-aware execution (like bucket shuffle joins) for Iceberg tables. The error happens because the code expects the data file to have a list of partition values (e.g., the bucket index), but the list is empty. This usually occurs in one of the following scenarios: 1. Partition Spec Evolution: You converted a previously unpartitioned Iceberg table to a bucketed one (or vice versa). Some older data files in S3 have no partition data (length 0), but the StarRocks planner is trying to access the first element (Index 0) based on the table's current bucketed spec. 2. Hidden Partitioning Conflict: The table uses Iceberg's "hidden partitioning" (e.g.,

bucket(N, column)

), and StarRocks' logic for identifying which partition field corresponds to the bucket is incorrectly accessing an empty array for certain splits. 3. Empty/Malformed Metadata: There may be an issue with the Iceberg metadata in S3 where a data file is registered without its expected partition values. Recommended Workarounds 1. Disable Bucket-Aware Optimization Since the crash occurs in the bucket extraction logic, you can try to disable the feature that triggers it. * For StarRocks v4.0+:

sql
    SET enable_bucket_aware_execution_on_lake = false;

* For StarRocks v3.x: Try disabling related optimizations that might be forcing the bucket lookup:

sql
    SET enable_iceberg_column_statistics = false;

2. Refresh Table Metadata If the issue is caused by stale metadata or a recent schema change that hasn't been fully propagated to the StarRocks FE cache:

sql
REFRESH EXTERNAL TABLE <your_table_name>;

3. Verify Partition Specs Check if your table has multiple partition specs or if some files are unpartitioned. You can query the Iceberg metadata table:

sql
SELECT * FROM <catalog>.<db>.<table>$partitions;
-- Also check the snapshots to see if they reference different specs
SELECT * FROM <catalog>.<db>.<table>$snapshots;

Recommendation This appears to be a known edge case in the StarRocks Iceberg connector's scan range builder. If the workarounds above do not resolve it, please provide your StarRocks version and the table schema (including the

PARTITIONED BY

clause). If you are using a version earlier than 3.3.x, upgrading to the latest maintenance release (e.g., 3.2.10+ or 3.3.3+) is recommended as there have been several fixes related to Iceberg partition transform handling (#71913, #71917). References • sql-reference/System_variable.md