You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Ramin Gharib (Jira)" <ji...@apache.org> on 2026/08/03 15:18:00 UTC

[jira] [Created] (FLINK-40318) Add a validation entry point for a VARIANT binary

Ramin Gharib created FLINK-40318:
------------------------------------

             Summary: Add a validation entry point for a VARIANT binary
                 Key: FLINK-40318
                 URL: https://issues.apache.org/jira/browse/FLINK-40318
             Project: Flink
          Issue Type: Improvement
          Components: API / Core
            Reporter: Ramin Gharib
            Assignee: Ramin Gharib


Flink has no way to check that a variant binary is well formed before using it. \{{BinaryVariant}} validates only the metadata version, and everything else relies on \{{checkIndex}} failing lazily during access.
 
Spark's \{{VariantUtil}}, which \{{BinaryVariantUtil}} is derived from, provides \{{isValidVariant(value, metadata)}} backed by a recursive \{{validateImpl}}. It checks the metadata version, structural well formedness of every value, access bounds, primitive type-info validity, dictionary-id existence for object fields, and recurses through nested objects and arrays. Neither method was carried over.
 
This matters once variant bytes arrive from outside the job, for example from a Parquet or Avro source or from restored state, where malformed input should be rejected up front with a clear error instead of surfacing as an index failure somewhere deep in a query.
 
h3. Scope
Port \{{isValidVariant}} and \{{validateImpl}}, and decide where to call them, most likely when constructing a \{{BinaryVariant}} from external bytes rather than on every access.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)