Open dougbu opened 5 months ago
@aaubry, this one is important in something I'd like to change in .NET build infrastructure. if you have a minute to suggest an approach, I'm happy to put some time into it :grin:
I’d have to double check but if the merging parser uses yamlstream under the hood then that makes sense because the stream calls dictionary.add without checking for duplicate keys. My suspicion is so that it will follow the spec. It was requested not to long ago to have that feature in the stream where duplicate keys would override the previous value, pretty sure that’s what it was.
Ignore my last comment. Way off base.
Describe the bug
As far as I can tell,
YamlDotNet
correctly handles duplicate key checking with YAML-spec-compliant anchors and aliases. However, theMergingParser
is unable to deserialize YAML using the proposed merge key whenDeserializerBuilder.WithDuplicateKeyChecking()
has been called.My initial thought for a potential fix would be tracking the anchor from which a key was previously set. While expanding a higher-level alias or a new map, duplicate keys should be ignored and handled as they are today when using
MergingParser
. I seeYamlNode.Anchor
exists but am not sure theMergingParser
,DictionaryDeserializer
, andObjectNodeDeserializer
can use this property to handle keys during merges correctly.To Reproduce
Add a test like
SerializationTests.ExampleFromSpecificationIsHandledCorrectly()
but with a new name and usinginstead of the inherited
Deserializer
property. Execute the new test.Expected
The test should work perfectly.
Actual
The test fails. In my branch, the error is
Debugging shows the incorrect detection occurs at the
<< : [ *BIG, *LEFT, *SMALL ]
line in the sample. I'm not positive (because I'm not familiar enough w/ the code) but suspect it's currently expanding the*BIG
alias.