prestodb/presto · error · PrestoException
ICEBERG_INVALID_METADATA
ICEBERG_INVALID_METADATA
Error message
No metadata found at location %s
What it means
ICEBERG_INVALID_METADATA thrown by resolveLatestMetadataLocation when, after successfully listing the metadata path, no Iceberg metadata JSON file (e.g. v1.metadata.json / v2.metadata.json) with a parseable version is found. It indicates the location is not a valid Iceberg table metadata directory.
Source
Thrown at presto-iceberg/src/main/java/com/facebook/presto/iceberg/procedure/RegisterTableProcedure.java:178
duplicateVersions = true;
long modifiedTime = file.getModificationTime();
if (modifiedTime > lastModifiedTime) {
lastModifiedTime = modifiedTime;
metadataFile = file.getPath();
}
}
}
}
catch (IOException io) {
throw new PrestoException(ICEBERG_FILESYSTEM_ERROR, format("Unable to find metadata at location %s", metadataPath), io);
}
if (duplicateVersions) {
clientSession.getWarningCollector().add(new PrestoWarning(MULTIPLE_TABLE_METADATA, format("Multiple metadata files of most recent version %d found at location %s. Using most recently modified version", maxVersion, metadataPath)));
}
if (metadataFile == null) {
throw new PrestoException(ICEBERG_INVALID_METADATA, format("No metadata found at location %s", metadataPath));
}
return metadataFile;
}
static int parseMetadataVersionFromFileName(String fileName)
{
Matcher matcher = METADATA_VERSION_PATTERN.matcher(fileName);
if (matcher.matches()) {
return parseInt(matcher.group("version"));
}
matcher = HADOOP_METADATA_VERSION_PATTERN.matcher(fileName);
if (matcher.matches()) {
return parseInt(matcher.group("version"));
}
return -1;
}
}View on GitHub (pinned to 55bb57d202)
Solutions
- Pass the correct location — typically the table's metadata/ directory, not the table root
- Confirm files like 00001.metadata.json (vN.metadata.json) exist at the location
- Check whether a retention/orphan-file cleanup job deleted the metadata files
- If versions exist but aren't detected, verify filenames match the expected vN.metadata.json pattern
Example fix
// before CALL system.register_table(schema => 's', table => 't', table_location => 'hdfs://ns/warehouse/t') // after CALL system.register_table(schema => 's', table => 't', table_location => 'hdfs://ns/warehouse/t/metadata')
Defensive patterns
Strategy: validation
Validate before calling
// Confirm versioned metadata JSON exists before invoking register_table
boolean hasMetadata = fs.listStatus(new Path(location)).length > 0 &&
Arrays.stream(fs.listStatus(new Path(location)))
.anyMatch(f -> f.getPath().getName().matches("v\\d+\.metadata\.json"));
if (!hasMetadata) throw new IllegalStateException("No vN.metadata.json at " + location); Prevention
- Point table_location at the metadata/ directory, not the table root
- Never let orphan-file cleanup delete vN.metadata.json files
- Verify the writer tool produces standard Iceberg metadata file names
- List the directory manually before running register_table
When it happens
Trigger: register_table invoked on a location whose metadata directory contains no versioned metadata JSON files — empty directory, only data files, or metadata files with unparseable version names.
Common situations: Pointing register_table at the table root instead of the metadata/ subdirectory; wrong location (data-only directory); table written by a different tool with nonstandard metadata naming; metadata files deleted by orphan cleanup.
Related errors
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/100757a204fbd722.
Report an issue: GitHub.