Open cdisselkoen opened 1 month ago
Noting that this issue is moot with RFC 70, as all three of the schemas above are invalid after RFC 70. However, we should still consider whether we need to fix this in 3.x (or any other versions that are released before RFC 70 ships, assuming it does indeed eventually ship).
I think a proper fix is essentially RFC 70.
Correct, the only question is do we want a (different, backwards-compatible) fix for 3.x
Before opening, please confirm:
Bug Category
Schemas and Validation
Describe the bug
For the following schema:
When converted to natural/human syntax, we get
(I added whitespace for clarity.)
When converting that back to JSON syntax, we get
(again, I added whitespace for clarity.)
This is not the same as the original schema: In the original schema,
Foo.owner
had the typeUser
, an entity type in the empty namespace. In the final schema,Foo.owner
has the typeNS::User
, a common type which resolves toString
.Due to the under-the-hood implementation where natural-syntax schemas are first translated into the JSON structures before processing, I'm pretty sure that in 3.2.1, the behavior of the natural-syntax schema is the same as that of the final schema. An important question is whether this is the correct behavior for the natural-syntax schema, according to the spec. I believe it is (even after #579 is fixed), because priority is given to definitions in the current namespace over definitions in the empty namespace. (RFC 24 also specifies that common-type definitions take priority over entity-type definitions, but I interpret that to be "in the same namespace", so it doesn't apply here. I also apply that interpretation in #1060.)
Assuming that the 3.2.1 interpretation of this natural-syntax schema is correct, the problem is in the first step above (converting from JSON to natural syntax), so probably in
json_schema_to_custom_schema_str()
inhuman_schema/fmt.rs
. This means the bug only affects the translation from JSON to human/natural syntax, and not the interpretation of any JSON or natural-syntax schemas in 3.2.1.Expected behavior
Converting the JSON schema to natural/human syntax and back should yield the same schema, or at least an equivalent one.
Reproduction steps
cargo install cedar-policy-cli@3.2.1
cedarschema.json
cedar translate-schema --direction json-to-human --schema cedarschema.json > cedarschema
cedarschema
should match what's written above, modulo whitespacecedar translate-schema --direction human-to-json --schema cedarschema > cedarschema_roundtripped.json
cedarschema_roundtripped.json
should match the final schema above, modulo whitespaceCode Snippet
No response
Log output
No response
Additional configuration
Reproduced on the 3.2.1 CLI
Operating System
No response
Additional information and screenshots
No response