prestodb/presto · error · PrestoException

ICEBERG_CANNOT_OPEN_SPLIT

ICEBERG_CANNOT_OPEN_SPLIT

Error message

Error opening Iceberg split %s (offset=%s, length=%s): %s

What it means

The fallback branch of the same error-handling block in IcebergPageSourceProvider.createParquetPageSource: any exception opening the Iceberg split that is neither a PrestoException, ParquetCorruptionException, nor BlockMissingException is rethrown as PrestoException with code ICEBERG_CANNOT_OPEN_SPLIT. It wraps the message 'Error opening Iceberg split ... (offset, length)' and the original cause. It indicates the connector could not open/access the file at all — I/O errors, permission issues, missing files other than HDFS BlockMissingException, etc.

Source

Thrown at presto-iceberg/src/main/java/com/facebook/presto/iceberg/IcebergPageSourceProvider.java:445

                if (dataSource != null) {
                    dataSource.close();
                }
            }
            catch (IOException ignored) {
            }
            if (e instanceof PrestoException) {
                throw (PrestoException) e;
            }
            String message = format("Error opening Iceberg split %s (offset=%s, length=%s): %s", path, start, length, e.getMessage());

            if (e instanceof ParquetCorruptionException) {
                throw new PrestoException(ICEBERG_BAD_DATA, message, e);
            }

            if (e instanceof BlockMissingException) {
                throw new PrestoException(ICEBERG_MISSING_DATA, message, e);
            }
            throw new PrestoException(ICEBERG_CANNOT_OPEN_SPLIT, message, e);
        }
    }

    public static Optional<org.apache.parquet.schema.Type> getColumnType(
            Map<Integer, org.apache.parquet.schema.Type> parquetIdToField,
            MessageType messageType,
            IcebergColumnHandle column)
    {
        if (isPushedDownSubfield(column)) {
            Subfield pushedDownSubfield = getPushedDownSubfield(column);
            List<String> encodedPath = nestedColumnPath(pushedDownSubfield).stream()
                    .map(AvroSchemaUtil::makeCompatibleName)
                    .collect(Collectors.toList());
            return getSubfieldType(messageType, AvroSchemaUtil.makeCompatibleName(pushedDownSubfield.getRootName()), encodedPath);
        }

        if (parquetIdToField.isEmpty()) {
            // This is a migrated table

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Read the wrapped cause (e) in the error message/stack trace to identify the root problem (missing file, permissions, timeout).
  2. If files were deleted concurrently (expireSnapshots/orphan cleanup), increase retention, prevent deletion during queries, and re-run; consider using Iceberg time travel/rollback to a valid snapshot.
  3. Fix storage access: verify credentials, IAM/HDFS permissions, bucket/container names, and network connectivity between workers and storage.
  4. For transient object-store throttling/timeouts, retry the query and tune S3 client settings (retries, connection pool, timeout) in the iceberg connector properties.
Defensive patterns

Strategy: try-catch

Validate before calling

// Check file existence/permissions before querying
// aws s3 ls s3a-bucket/table/data/  (or hdfs dfs -ls /warehouse/db/table)
// Validate connector storage config: iceberg.s3.path-style-access, credentials, region

Try / catch

try {
    queryResults = execute("SELECT * FROM iceberg_table");
} catch (PrestoException e) {
    if ("ICEBERG_CANNOT_OPEN_SPLIT".equals(e.getErrorCode().getName())) {
        // inspect wrapped cause: FileNotFoundException -> snapshot expiry;
        // permission/timeout -> fix storage access; transient -> retry with backoff
        diagnoseCause(e.getCause());
    } else {
        throw e;
    }
}

Prevention

When it happens

Trigger: createDataPageSource -> createParquetPageSource catching a raw IOException/RuntimeException from the file system or HdfsInput while opening the split's Parquet file — e.g. FileNotFoundException (object deleted from S3), permission denied, throttling/timeout errors from object store, or network I/O failure.

Common situations: Files deleted by snapshot expiry/orphan cleanup while a long-running query was executing; wrong S3/HDFS credentials or bucket config; S3 503/timeout throttling; file moved by external processes; transient network partitions between Presto workers and storage.

Related errors


AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/a82fe85b7005eaed. Report an issue: GitHub.