Skip to content

parquet-reader outputting invalid JSON #47668

Closed as duplicate
Closed as duplicate

Description

@alexey-milovidov

Describe the bug, including details regarding any error messages, version, and platform.

Example output without this:

{
  "FileName": "/home/ubuntu/ClickHouse/tests/queries/0_stateless/data_parquet/68131.parquet",
  "Version": "1.0",
  "CreatedBy": "parquet-mr version 1.12.2 (build 77e30c8093386ec52c3cfa6c34b7ef3321322c94)",
  "TotalRows": "1",
  "NumberOfRowGroups": "1",
  "NumberOfRealColumns": "1",
  "NumberOfColumns": "1",
  "Columns": [
     { "Id": "0", "Name": "f", "PhysicalType": "INT32", "ConvertedType": "NONE", "LogicalType": {"Type": "None"} }
  ],
  "RowGroups": [
     {
       "Id": "0",  "TotalBytes": "43",  "TotalCompressedBytes": "43",  "Rows": "1",
       "ColumnChunks": [
          {"Id": "0", "Values": "2", "StatsSet": "True", "Stats": {"NumNulls": "0", "Max": "2", "Min": "1" },
           "Compression": "UNCOMPRESSED", "Encodings": "PLAIN", "UncompressedSize": "43", "CompressedSize": "43", ColumnIndex {"offset": "47", "length": "23"}", OffsetIndex {"offset": "70", "length": "10"}" }
        ]
     }
  ]
}

It goes off the rails starting at ColumnIndex.

ClickHouse uses this tool in test 00900_long_parquet_load (ran manually to get table schemas).

The fix is here: ClickHouse#72

Component(s)

C++

Activity

  1. stackedsax commented on Oct 4, 2026

    @stackedsax

    This was fixed upstream in #44532 (GH-44101), released in Arrow 19.0.0. The malformed ColumnIndex {...}" output came from a stray string literal in printer.cc introduced by #38860 (18.0.0); #44532 corrected it to emit "ColumnIndex": {"offset": ..., "length": ...}.

    Since then the printer has been migrated to a proper JsonWriter (#50877, #50990), so malformed keys of this kind are structurally impossible now, and #47190 added a ValidJsonOutput test in reader_test.cc that parses the printer's output to make sure it stays valid JSON.

    ClickHouse's fork (ClickHouse#72, linked above) is based on release/16.1.0, which predates the fix, so the fork would need to rebase or cherry-pick f5691d4 rather than anything changing here.

    @thisisnic I think this one can be closed as fixed.

    Note: I used Claude Code to help research this, but I read the ticket, the code and the linked commits myself and the conclusion here is mine, not the tool's.

  2. adamreeve commented on Oct 13, 2026

    @adamreeve
    Contributor

    Thanks for the investigation @stackedsax!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions