Repository navigation
Provide non-source-location context for errors in schema parsing #435
Description
Category
Cedar validation features
Describe the feature you'd like to request
When schema construction fails we currently do not have a good way to report source locations if it fails after serde finishes the initial parse from JSON (#174). We should instead (or in addition) report more information about the context of the error, including at least the entity type, common type, or action where the error occurred.
For example, all of these errors are difficult to diagnose, particularly in a large schema because the message gives no indication of where to look for the error.
For this error we should report that the error occurred in `memberOfTypes` list for `User` entity type instead of just in entity type.
{
"": {
"entityTypes": {
"User": {
"memberOfTypes": [""]
}
},
"actions": {}
}
}This should also work for a parse error in the entity type itself, so this could say parsing name of `My Entity Type` entity type.
{
"": {
"entityTypes": {
"My Entity Type": {}
},
"actions": {}
}
}And for a common type name. This could be: parsing name of `My Common Type` common type.
{
"MyNameSpace": {
"commonTypes": {
"My Common Type": {
"type": "String"
}
},
"entityTypes": {},
"actions": {}
}
}See #349 for more errors that could be improved.
Activity
[-]Provide non-source-location context for errors is schema parsing[/-][+]Provide non-source-location context for errors in schema parsing[/+]Update for cedar#1202 (revert #420) (#435)
Say which declaration a JSON schema error is in (fixes cedar-policy#435)
Vedthakar commentedon Oct 25, 2026
I opened #2650 for this: errors while reading a JSON schema are now prefixed with the declaration they come from, e.g.
in entity type \User`: ...`.— Ved Thakar