prestodb/presto · error · PrestoException

MALFORMED_QUERY_FILE

MALFORMED_QUERY_FILE

Error message

sql file size %s is different from expected sqlFileSizeInBytes %s

What it means

When a Spark query is submitted with sqlLocation (SQL read from metadata storage) plus an expected sqlFileSizeInBytes, PrestoSparkQueryExecutionFactory verifies the downloaded file length matches the declared size. A mismatch means the SQL file was corrupted, truncated, or changed after hashing; it throws MALFORMED_QUERY_FILE. This guards against executing a different query than the submitter intended.

Source

Thrown at presto-spark-base/src/main/java/com/facebook/presto/spark/PrestoSparkQueryExecutionFactory.java:578

            PrestoSparkTaskExecutorFactoryProvider executorFactoryProvider,
            Optional<String> queryStatusInfoOutputLocation,
            Optional<String> queryDataOutputLocation,
            List<ExecutionStrategy> executionStrategies,
            Optional<CollectionAccumulator<Map<String, Long>>> bootstrapMetricsCollector)
    {
        PrestoSparkConfInitializer.checkInitialized(sparkContext);

        String sql;
        if (sqlText.isPresent()) {
            checkArgument(!sqlLocation.isPresent(), "sqlText and sqlLocation should not be set at the same time");
            sql = sqlText.get();
        }
        else {
            checkArgument(sqlLocation.isPresent(), "sqlText or sqlLocation must be present");
            byte[] sqlFileBytes = metadataStorage.read(sqlLocation.get());
            if (sqlFileSizeInBytes.isPresent()) {
                if (Integer.valueOf(sqlFileSizeInBytes.get()) != sqlFileBytes.length) {
                    throw new PrestoException(
                            MALFORMED_QUERY_FILE,
                            format("sql file size %s is different from expected sqlFileSizeInBytes %s", sqlFileBytes.length, sqlFileSizeInBytes.get()));
                }
            }
            if (sqlFileHexHash.isPresent()) {
                try {
                    MessageDigest md = MessageDigest.getInstance("SHA-512");
                    String actualHexHashCode = BaseEncoding.base16().lowerCase().encode(md.digest(sqlFileBytes));
                    if (!sqlFileHexHash.get().equals(actualHexHashCode)) {
                        throw new PrestoException(
                                MALFORMED_QUERY_FILE,
                                format("actual hash code %s is different from expected sqlFileHexHash %s", actualHexHashCode, sqlFileHexHash.get()));
                    }
                }
                catch (NoSuchAlgorithmException e) {
                    throw new PrestoException(GENERIC_INTERNAL_ERROR, "unsupported hash algorithm", e);
                }
            }

View on GitHub (pinned to 55bb57d202)

Solutions

Re-upload the SQL file and resubmit, ensuring sqlFileSizeInBytes is recomputed from the final bytes of the same file
Verify the file in metadata storage was not modified between submission and launch (check timestamps/checksums)
If integrity checking is not needed, omit sqlFileSizeInBytes and rely on the hex hash instead (or neither)

Example fix

// before: size computed before final write
long size = oldBytes.length;
storage.write(path, newBytes);
new PrestoSparkQueryExecution(..., sqlLocation, Optional.of((int) size), ...);
// after
storage.write(path, newBytes);
new PrestoSparkQueryExecution(..., sqlLocation, Optional.of(newBytes.length), ...);

Defensive patterns

Strategy: validation

Validate before calling

byte[] bytes = storage.read(sqlLocation);
if (sqlFileSizeInBytes != null && bytes.length != sqlFileSizeInBytes) {
    throw new IllegalStateException("SQL file changed after submission; re-upload and resubmit");
}

Try / catch

try {
    QueryExecution qe = factory.create(queryExecutionConfig);
} catch (PrestoException e) {
    if ("MALFORMED_QUERY_FILE".equals(e.getErrorCode().getName())) {
        // re-upload SQL file and resubmit the query
    } else throw e;
}

Prevention

Compute sqlFileSizeInBytes from the exact uploaded bytes, after the final write
Write SQL files immutably (unique names) to shared storage
Avoid editing SQL files between submission and execution
Prefer hex-hash verification over size-only checking

When it happens

Trigger: Submitting a query with both sqlLocation and sqlFileSizeInBytes where the byte length of metadataStorage.read(sqlLocation) differs from sqlFileSizeInBytes (e.g. the file was edited after submission, or the size was computed on different content).

Common situations: Overwriting the SQL file in shared storage between job submission and execution; manual edits to the uploaded SQL file; client computing the size from a different file than uploaded; storage truncation.

Related errors

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