-
Notifications
You must be signed in to change notification settings - Fork 10
fix: Fix yaml validation for key named "type" #588
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
base: main
Are you sure you want to change the base?
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! |
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
cerberus
library 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_management
andcomponent_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
anyof
union type offered by the library.When declaring the schema type is
anyof
with 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 type
instead of original errornone is not iterable
which 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