[ 
https://issues.apache.org/jira/browse/AVRO-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17646624#comment-17646624
 ] 

Rik Heijdens commented on AVRO-3688:
------------------------------------

Extended the Pull Request with a fix in: 
https://github.com/apache/avro/pull/2011/commits/b481f5ed3ade360403754bbb6ee9a70cdec5909c

My understanding of the root cause of this issue is the following: a Union 
field may contain any `Schema` variant, including a `Schema::Ref`, i.e. a 
reference to another schema. If we try to resolve the schemas contained in the 
union prior to resolving the schema reference, then schema resolution will 
fail, causing an unhandled panic.

My fix prevents the unhandled panic by ensuring that the schemas contained in 
the Union are resolved prior to resolving the Union itself.

> Schema resolution panics when a custom record field is included multiple times
> ------------------------------------------------------------------------------
>
>                 Key: AVRO-3688
>                 URL: https://issues.apache.org/jira/browse/AVRO-3688
>             Project: Apache Avro
>          Issue Type: Bug
>            Reporter: Rik Heijdens
>            Priority: Major
>
> Consider the following Avro schema:
> {noformat}
> {
>     "type": "record",
>     "name": "Message",
>     "fields": [
>         {
>             "name": "field_a",
>             "type": [
>                 "null",
>                 {
>                     "name": "Inner",
>                     "type": "record",
>                     "fields": [
>                         {
>                             "name": "inner_a",
>                             "type": "string"
>                         }
>                     ]
>                 }
>             ],
>             "default": null
>         },
>         {
>             "name": "field_b",
>             "type": [
>                 "null",
>                 "Inner"
>             ],
>             "default": null
>         }
>     ]
> }{noformat}
> This can be represented in Rust through the following structs:
> {noformat}
> #[derive(Serialize, Deserialize)]
> struct Inner {
>     inner_a: String
> }
> #[derive(Serialize, Deserialize)]
> struct Message {
>     field_a: Option<Inner>,
>     field_b: Option<Inner>
> }
> {noformat}
> If I instantiate an instance of `message`, set `field_a` and then serialize 
> it using the following code:
> {noformat}
>         let schema = Schema::parse_str(&schema_str).unwrap();
>         let msg = Message {
>             field_a: Some(Inner {
>                 inner_a: "foo".to_string()
>             }),
>             field_b: None
>         };
>         let mut ser = Serializer::default();
>         let test_value: Value = msg.serialize(&mut ser).unwrap();
>         assert!(test_value.validate(&schema), "test_value should validate");
>         assert!(
>             test_value.resolve(&schema).is_ok(),
>             "test_value should resolve"
>         );
> {noformat}
> Then my assertions pass. However if I set field_b to `Inner`, then my call to 
> `test_value.resolve(&schema)` panics:
> {noformat}
> let schema = Schema::parse_str(&schema_str).unwrap();
> let msg = Message {
>     field_a: Some(Inner {
>         inner_a: "foo".to_string()
>     }),
>     field_b: Some(Inner {
>         inner_a: "bar".to_string()
>     })
> };
> let mut ser = Serializer::default();
> let test_value: Value = msg.serialize(&mut ser).unwrap();
> assert!(test_value.validate(&schema), "test_value should validate");
> assert!(
>     test_value.resolve(&schema).is_ok(),
>     "test_value should resolve"
> );
> {noformat}
> This seems to be a bug in the schema resolution logic that's causing an 
> unhandled panic.



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

Reply via email to