-
Notifications
You must be signed in to change notification settings - Fork 11
fix: Fix yaml validation for key named "type" #588
Conversation
CodSpeed Performance ReportMerging #588 will not alter performanceComparing Summary
|
9158495 to
4203249
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #588 +/- ##
==========================================
- Coverage 88.62% 88.59% -0.04%
==========================================
Files 462 463 +1
Lines 12875 12786 -89
Branches 1461 1458 -3
==========================================
- Hits 11411 11328 -83
+ Misses 1159 1153 -6
Partials 305 305
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Codecov ReportAll modified and coverable lines are covered by tests ✅ ✅ All tests successful. No failed tests found. 📢 Thoughts on this report? Let us know! |
ajay-sentry
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very cool! I wish the wording of the message was of format must be of type list rather than must be of list type but thats outside of our control seems like :(
Thanks for documenting this thoroughly!
The
cerberuslibrary that we use for yaml validation has a bug when a schema field is named "type," a reserved word (see similar unresolved bug report in their repo here).This results in codecov yaml validator returns 500 internal server error instead of a more specific validation error if you accidentally pass an object instead of a list under
flag_managementandcomponent_management(as was reported here).Aside from waiting for the underlying library to fix the issue (or vendoring the library and fixing it in our own copy), it seems we can use a workaround with the
anyofunion type offered by the library.When declaring the schema type is
anyofwith a single element describing the expected shape, we can get around the problem, as done in this PR.So now it will return error
must be of list typeinstead of original errornone is not iterablewhich happens when you try to iterate over none at hereSo that will give a richer error message for this edge case of schema fields named "type", and expecting a list instead of an object.
Note that the error message for extraneous subfields becomes slightly different with "unknown field" instead of "extra keys not allowed" (see updated test)
Closes codecov/feedback#146