[SPARK-45891][SQL][FOLLOW-UP] Added length check to the is_variant_null expression #46311
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ng with parse_json and variant_get
…authentication errors
harshmotw-db
force-pushed
the
is_variant_null_fix
branch
from
332a270
to
8be9630
Compare
cloud-fan
approved these changes
May 1, 2024
HyukjinKwon
approved these changes
May 1, 2024
dongjoon-hyun
changed the title
...ain/scala/org/apache/spark/sql/catalyst/expressions/variant/VariantExpressionEvalUtils.scala
Outdated
Show resolved
Hide resolved
...ain/scala/org/apache/spark/sql/catalyst/expressions/variant/VariantExpressionEvalUtils.scala
Outdated
Show resolved
Hide resolved
dongjoon-hyun
approved these changes
May 1, 2024
|
Thanks for the reviews @cloud-fan @HyukjinKwon @dongjoon-hyun. The tests are completed and it is ready to be merged now. |
|
Yep. Merged to master for Apache Spark 4.0.0. Thank you, @harshmotw-db . |
JacobZheng0927
pushed a commit
to JacobZheng0927/spark
that referenced
this pull request
May 11, 2024
…ll expression ### What changes were proposed in this pull request? Added a check in the `is_variant_null` expression where the length of the value field is verified to be greater than zero. If the length is zero, a `MALFORMED_VARIANT` exception is thrown. ### Why are the changes needed? Earlier, `is_variant_null` was simply checking if the first byte of a variant value was zero. However, if the value field is empty, the first byte logically doesn't exist and therefore, it could result in undefined behavior. Such a case should ideally never be seen but it could appear in the case of data corruption. ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Additional unit test to check if the zero-length variant throws an exception. ### Was this patch authored or co-authored using generative AI tooling? No Closes apache#46311 from harshmotw-db/is_variant_null_fix. Authored-by: Harsh Motwani <harsh.motwani@databricks.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Added a check in the
is_variant_nullexpression where the length of the value field is verified to be greater than zero. If the length is zero, aMALFORMED_VARIANTexception is thrown.Why are the changes needed?
Earlier,
is_variant_nullwas simply checking if the first byte of a variant value was zero. However, if the value field is empty, the first byte logically doesn't exist and therefore, it could result in undefined behavior. Such a case should ideally never be seen but it could appear in the case of data corruption.Does this PR introduce any user-facing change?
No
How was this patch tested?
Additional unit test to check if the zero-length variant throws an exception.
Was this patch authored or co-authored using generative AI tooling?
No