-
Notifications
You must be signed in to change notification settings - Fork 35
fix(CedarJavaFFI): exhaustive match broken on EntitiesError update #366
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -506,12 +506,16 @@ pub fn validate_entities(input: &str) -> serde_json::Result<Answer> { | |
|
|
||
| match CedarEntities::from_json_value(validate_entity_call.entities, Some(&schema)) { | ||
| Err(error) => { | ||
| // Unwrap only the variants whose own `Display` impl summarizes instead of | ||
| // delegating, so the caller keeps the specific inner diagnostic. The rest | ||
| // are `#[error(transparent)]` or already interpolate their source, so the | ||
| // catch-all preserves their detail and keeps this compiling when upstream | ||
| // adds a variant. | ||
| let err_message = match error { | ||
| EntitiesError::Serialization(err) => err.to_string(), | ||
| EntitiesError::Deserialization(err) => err.to_string(), | ||
| EntitiesError::Duplicate(err) => err.to_string(), | ||
| EntitiesError::TransitiveClosureError(err) => err.to_string(), | ||
| EntitiesError::InvalidEntity(err) => err.to_string(), | ||
| err => err.to_string(), | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If someone adds a new There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The issue you have is that right now, your consumers are the ones broken since your own package doesn't lock down to compatible versions in any way and this is why libraries with Enums they plan to update often add a So the ask would be either to:
Otherwise you're just making all of your consumers have to lock or constrain otherwise transitive dependencies that they don't directly use. I'm not saying it isn't an available tool, but it's effectively passing breakages to your consumers for reporting them much like this one which doesn't engender trust if that isn't well-understood at outset.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The new error message variant shouldn't have made it into the release. We have cargo-semver-checks to guard against this, but it's not perfect. Probably the best option for now is to roll forward, leaving the new variant in place and patching the Java as propsed here. Adding
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed with the above! In that case, are we aligned on this change to patch Cedar Java? |
||
| }; | ||
| Ok(Answer::fail_bad_request(vec![err_message])) | ||
| } | ||
|
|
||
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.
Leaving this here until #365 is merged. I can also implement this case along with #365