prestodb/presto · error · ParquetDecodingException

not a valid mode

Error message

not a valid mode 

What it means

BaseRLEBitPackedDecoder.decode reads one RLE/bit-packed hybrid run; the first varint's LSB holds the mode. Only Mode.RLE (0) and Mode.PACKED_BIT_PACKED (1) are handled; any other mode value is corrupt/unknown and decode throws a ParquetDecodingException. This is the lowest-level guard for the hybrid encoding header in the batch reader.

Source

Thrown at presto-parquet/src/main/java/com/facebook/presto/parquet/batchreader/decoders/rle/BaseRLEBitPackedDecoder.java:119

                return true;
            case PACKED:
                int numGroups = header >>> 1;
                currentCount = numGroups * 8;
                currentBuffer = new int[currentCount];
                byte[] bytes = new byte[numGroups * bitWidth];
                int bytesToRead = (int) ceil((double) (currentCount * bitWidth) / 8.0D);
                bytesToRead = Math.min(bytesToRead, inputStream.available());
                DataInputStream dataInputStream = new DataInputStream(inputStream);
                dataInputStream.readFully(bytes, 0, bytesToRead);
                int valueIndex = 0;

                for (int byteIndex = 0; valueIndex < currentCount; byteIndex += bitWidth) {
                    packer.unpack8Values(bytes, byteIndex, currentBuffer, valueIndex);
                    valueIndex += 8;
                }
                return true;
            default:
                throw new ParquetDecodingException("not a valid mode " + mode);
        }
    }

    public enum Mode
    {
        RLE,
        PACKED
    }
}

View on GitHub (pinned to 55bb57d202)

Solutions

1. Validate the file with parquet-tools to locate the corrupt column chunk
2. Re-copy/re-download the file and compare checksums to rule out truncation
3. Rewrite the affected file with a standard writer using RLE encoding
4. If the file is valid in other readers, file a bug with offset details — the reader may be mispositioned

Example fix

// before: truncated upload leaves run header byte = 0x9A -> unknown mode
// after: restore the file from a verified source
//   hadoop fs -checksum src dst  # then retry the query

// Detect truncation/corruption before reading:
// parquet-tools meta file.parquet  # fails fast on corrupt chunk headers

try {
    decoder.decode(valuesToRead);
} catch (ParquetDecodingException e) {
    if (e.getMessage().startsWith("not a valid mode")) {
        throw new IOException("Corrupt RLE/bit-packed header, file may be truncated", e);
    }
    throw e;
}

When it happens

Trigger: decode() reads a run header whose mode bits are neither 0 (RLE) nor 1 (PACKED_BIT_PACKED) — e.g. a garbage/truncated header byte or a writer emitting an invalid mode.

Common situations: Corrupted or truncated column chunks (partial upload, bad compaction); files written by non-standard or buggy Parquet writers; reading at a wrong offset so random bytes are interpreted as a run header.

Related errors

• not a valid mode
• not a valid mode
• not a valid mode
• could not decode the dictionary for
• could not decode the dictionary for

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