Older `parquet-java` readers fail on files with unprojected VARIANT columns

まず ParquetMetadataConverter.getLogicalTypeAnnotation と ParquetMetadataConverter.java 内のスタック位置を確認し、次に parquet-testing/shredded_variant/case-001.parquet に対して失敗している TestReadWithUnknownLogicalType テストを実行します。完了の条件は、id の射影読み取りが射影されていない VARIANT 列を許容し、サポートされていないフィールドについては意味的に読み取られた場合にのみ引き続き失敗することです。

Summary

parquet-java 1.15.x fails when opening a Parquet file that contains a VARIANT column, even if the application only requests other columns and does not request the VARIANT column.

The failure happens while converting the footer schema, before projection is applied. The parquet-format compatibility guidance says that new logical types are intended to be forward compatible: https://github.com/apache/parquet-format/blob/master/CONTRIBUTING.md#compatibility-and-feature-enablement

Based on that, I think older readers should be able to tolerate an unknown logical type when that field is not part of the requested projection.

Repro

This can be reproduced with the VARIANT fixture in apache/parquet-testing:

git clone https://github.com/apache/parquet-testing.git
PARQUET_FILE="$PWD/parquet-testing/shredded_variant/case-001.parquet"

The file contains an id column and a var column annotated with VARIANT.

Using parquet-java 1.15.x, try to read only id through the normal GroupReadSupport projection path:

Path input = new Path(args[0]);

try (ParquetReader<Group> reader = ParquetReader.builder(new GroupReadSupport(), input)
    .set(
        ReadSupport.PARQUET_READ_SCHEMA,
        "message root {\n" + "optional int32 id;\n" + "}")
    .build()) {
  Group row = reader.read();
  System.out.println(row.getInteger("id", 0));
}

I also put up a draft repro PR with a failing unit test against parquet-1.15.x: https://github.com/kevinjqliu/parquet-java/pull/1

That test uses apache/parquet-testing/shredded_variant/case-001.parquet and requests only the id column. It still fails while reading footer metadata, before the projected read can happen.

Actual behavior

The read fails during footer schema conversion:

[ERROR] org.apache.parquet.hadoop.TestReadWithUnknownLogicalType.testReadProjectedColumnFromFileWithUnknownLogicalType -- Time elapsed: 0.283 s <<< ERROR!
java.lang.NullPointerException: Cannot invoke "org.apache.parquet.format.LogicalType$_Fields.ordinal()" because the return value of "org.apache.parquet.format.LogicalType.getSetField()" is null
    at org.apache.parquet.format.converter.ParquetMetadataConverter.getLogicalTypeAnnotation(ParquetMetadataConverter.java:1174)
    at org.apache.parquet.format.converter.ParquetMetadataConverter.buildChildren(ParquetMetadataConverter.java:1892)
    at org.apache.parquet.format.converter.ParquetMetadataConverter.fromParquetSchema(ParquetMetadataConverter.java:1840)
    at org.apache.parquet.format.converter.ParquetMetadataConverter.fromParquetMetadata(ParquetMetadataConverter.java:1670)
    at org.apache.parquet.format.converter.ParquetMetadataConverter.readParquetMetadata(ParquetMetadataConverter.java:1630)
    at org.apache.parquet.hadoop.ParquetFileReader.readFooter(ParquetFileReader.java:629)
    at org.apache.parquet.hadoop.ParquetFileReader.<init>(ParquetFileReader.java:934)
    at org.apache.parquet.hadoop.ParquetFileReader.<init>(ParquetFileReader.java:925)

The stack points to ParquetMetadataConverter.getLogicalTypeAnnotation.

Expected behavior

Older readers should tolerate an unknown logical type in the footer when the field is not projected, preserving the physical schema or treating the field as having no known logical annotation.

They should only fail if the unsupported field is actually read or interpreted semantically.

Notes

This is relevant for files written by newer or external writers that contain VARIANT, where older readers only need unrelated columns.