Binary statistics truncation test ignores its configured truncation length
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- java
- Domain
- testing-qa
Research direction
Start in TestParquetMetadataConverter.testBinaryStatsWithTruncation and inspect the ParquetMetadataConverter overloads used by the helper. Run that focused test, switch it to the explicit truncation-length overload, and make the assertions cover exact truncated values plus the strict 4095-byte accepted and 4096-byte omitted combined-size boundaries.
Written by the indexing model from the issue text.
Description
Describe the bug, including details regarding any error messages, version, and platform.
In TestParquetMetadataConverter.testBinaryStatsWithTruncation, the helper creates new ParquetMetadataConverter(truncateLen) but then calls metadataConverter.toParquetStatistics(stats). That method is static and delegates to DEFAULT_STATISTICS_TRUNCATE_LENGTH (Integer.MAX_VALUE), so the requested length never reaches conversion.
The existing assertions do not detect this: unchanged under-limit bounds satisfy the non-strict ordering checks, while oversized inputs are expected to have no bounds, matching the unintended default path. The test therefore does not exercise the finite truncation it describes.
This remains present at master 4b37c193e2f796d553a20cc57ec9835ceaa1c95c. For a deterministic example, minimum a repeated 60 times and maximum b repeated 70 times with length 1 should produce min_value="a" and max_value="c" through the explicit overload. The current helper uses the default overload and leaves those bounds untruncated.
The proposed correction is test-only: call toParquetStatistics(stats, truncateLen), use deterministic exact-byte assertions, and cover the strict 4095-byte accepted/4096-byte omitted combined-size boundary before and after truncation. Constructor validation and current null-count omission behavior remain unchanged.
#3819 addresses null-count serialization in production; this issue concerns a separate gap in truncation-test coverage and does not propose changing that behavior.
Component(s)
Core (parquet-hadoop)
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 1.6k
- Avg merge
- 4d 9h
- Merged PRs (30d)
- 32
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/parquet-java
-
Type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
apache/parquet-java#3792 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
apache/parquet-java#3767 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/parquet-java#3695 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/parquet-java#3667 ·
Maintainers usually reply within 1 day
-
Type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/parquet-java#3574 · 1 comment ·
Maintainers usually reply within 1 day
All issues in apache/parquet-java
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
openhab/openhab-core#5847 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
beehive-lab/jllm#187 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day