prestodb/presto · error · ParquetDecodingException

not a valid mode

Error message

not a valid mode 

What it means

FlatDefinitionLevelDecoder.readNext reads definition levels in either RLE or bit-packed mode. When the encoded chunk header contains a mode value other than Mode.RLE or Mode.PACKED_BIT_PACKED, the decoder cannot interpret the data and throws a ParquetDecodingException with the raw mode value. This means the definition-level stream is corrupt, was written by an unsupported writer, or the decoder is being pointed at the wrong byte offset.

Source

Thrown at presto-parquet/src/main/java/com/facebook/presto/parquet/batchreader/decoders/FlatDefinitionLevelDecoder.java:74

                case RLE: {
                    boolean rleValue = currentValue == 0;
                    while (destinationIndex < endIndex) {
                        values[destinationIndex++] = rleValue;
                    }
                    nonNullCount += currentValue * chunkSize;
                    break;
                }
                case PACKED: {
                    int[] buffer = currentBuffer;
                    for (int sourceIndex = buffer.length - currentCount; destinationIndex < endIndex; sourceIndex++, destinationIndex++) {
                        final int value = buffer[sourceIndex];
                        values[destinationIndex] = value == 0;
                        nonNullCount += value;
                    }
                    break;
                }
                default:
                    throw new ParquetDecodingException("not a valid mode " + mode);
            }
            currentCount -= chunkSize;
            remainingToCopy -= chunkSize;
        }

        checkState(remainingToCopy == 0, "Failed to copy the requested number of definition levels");
        return nonNullCount;
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Verify the Parquet file is readable with parquet-tools/parquet-cli and inspect the definition-level encoding for the affected column
2. Re-write the file with a standard writer (parquet-mr, Spark, Trino) so definition levels use RLE encoding
3. Upgrade presto-parquet to a version supporting the file's encoding/mode
4. If the file is fine, check for misaligned offsets/metadata in the reader path and report a bug with the file and query

Example fix

// No code fix on caller side; file-level fix:
// before: file written with unsupported def-level mode in column chunk
// after: rewrite file so column chunk uses PLAIN + RLE definition levels
//   e.g. in Spark: df.write.parquet(...) with default parquet writer

// Before querying, validate the file's column chunk encodings with parquet-tools:
// parquet-tools meta file.parquet | awk '/<target column>/ && $0 !~ /RLE/ {print "unsupported def-level encoding", $0}'

try {
    recordReader.nextBatch(block);
} catch (ParquetDecodingException e) {
    if (e.getMessage().startsWith("not a valid mode")) {
        // quarantine file, fall back to a repaired copy
    }
    throw e;
}

When it happens

Trigger: readNext() encounters a hybrid (RLE/bit-packed) definition-level chunk whose header mode byte is neither RLE nor PACKED (e.g. mode value 3 or garbage bytes); callers include nonNullCount, rleOnlyBlockHelper, hybridReadInBatchesHelper, and tryReadingTooMany.

Common situations: Reading a Parquet file written by a non-conforming writer; truncated or corrupted definition-level column chunk; wrong column metadata offsets after a version change of parquet-mr or the Presto parquet reader; files with experimental/unsupported encodings for definition levels.

Related errors

• could not decode the dictionary for
• could not decode the dictionary for
• Unsupported Parquet encoding:
• Failed to decode.
• We didn't read correct number of definitionLevels

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