I would appreciate any further insight on this though, as I'm not sure if it's the right approach.

Me too :-/

How is a_non_existing_enum supposed to be handled ? It seems it is just being ignored in your example. Why ?

It seems it is just being ignored in your example. Why ?

I still do not understand why it behaves like that but I see that the test does the same for all other fields, so you just follow the pattern.
If you understand why the extra record fields are being silently ignored please share!

Thank you, @xordi !

Ignoring those fields is on purpose, as I'd like to be able to deserialize the Value into a struct with just a subset of the fields that are present in the Value::Record.

serde produces a Deserialize implementation on the type that accounts for ignored fields. Basically that implementation calls deserialize_ignored_any in the Deserializer when handling a field that's not present in the target element (a struct in this case). I guess the main reason of this is because in some data formats, you need to read the underlying stream of data and ignore it in order to decode the next elements. In this crate case, the Deserializer forwards deserialize_ignored_any (called by the serde implementation of Deserialize on the struct) to deserialize_any, where the Enum values are not handled.

I followed the same pattern as for the other Value types in this fix, as this is actually implemented for mostly all of them except for Enum. I wonder if there was any reason why this behavior was not replicated for enums. I don't see any, but of course I might lack a lot of context.

Maybe another option not impacting this crate would be to manually implement Deserialize for a struct in which we just want to deserialize certain fields from the Value::Record, but given that the Deserializer implementation was already ignoring fields of other types, I opted to implement the same for enums.