RLE decoding should treat 0 length runs as error
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 1.6k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 33
Description
RunLengthBitPackingHybridDecoder accepts run headers that encode 0 length repeated runs, and treats them as if they were 2^32 length run, so effectively every value returned for that data page will be the same. (see https://github.com/apache/parquet-mr/blob/0a86429939075984edce5e3b8195dfb7f9e3ab6b/parquet-column/src/main/java/org/apache/parquet/column/values/rle/RunLengthBitPackingHybridDecoder.java#L66 )
Throwing an exception if count is 0 would give a proper error message for some corrupt files, and would make it clear that these are not legal values.
**Reporter**: [Csaba Ringhofer](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=csringhofer) / @csringhofer
**Note**: *This issue was originally created as [PARQUET-1250](https://issues.apache.org/jira/browse/PARQUET-1250). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in parquet-column/src/main/java/org/apache/parquet/column/values/rle/RunLengthBitPackingHybridDecoder.java at the linked line where the run count is decoded. Trace the handling of a zero count and add coverage for the corrupt header case. Done means zero-length runs produce an exception instead of being treated as a very large run.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- data-engineering
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100