Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid panics on error while encoding/decoding ListValue::Array as protobuf #7837

Merged
merged 1 commit into from
Oct 17, 2023

Conversation

alamb
Copy link
Contributor

@alamb alamb commented Oct 16, 2023

Which issue does this PR close?

Follow on to #7629

Rationale for this change

I noticed some panics while reviewing #7629 from @jayzhan211 but I didn't want to delay merging that PR any longer.

What changes are included in this PR?

This commit avoids panics in the error handling in the ScalarValue::List protobuf encoding by using the ? operator
instead unwrap. It also removes some unused variants that are no longer used after
#7629

Are these changes tested?

By existing tests and the rust compiler

Are there any user-facing changes?

Less panics on bad data


// TODO: Add comment to why adding 0 before arrow_data.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 0 was added in the arrow.rs code as it was a test for unaligned data. The zero is not needed for this cod

cc @jayzhan211

@@ -56,13 +56,6 @@ use datafusion_expr::{
pub enum Error {
General(String),

InconsistentListTyping(DataType, DataType),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These variants are no longer used

@@ -655,29 +656,36 @@ impl TryFrom<&protobuf::ScalarValue> for ScalarValue {
let schema: Schema = if let Some(schema_ref) = schema {
schema_ref.try_into()?
} else {
return Err(Error::General("Unexpected schema".to_string()));
return Err(Error::General(
Copy link
Contributor

@comphead comphead Oct 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we return some of Datafusion Errors instead? Maybe IoError or InternalError?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure why the from_proto and to_proto modules have their own error types and don't use DataFusionError (or even wrap DataFusionError)

It does seem like that would be an improvement. Maybe I can file a follow on ticket to do so.

Copy link
Contributor

@jayzhan211 jayzhan211 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks, @alamb !

@Dandandan Dandandan merged commit 2cd1706 into apache:main Oct 17, 2023
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants