Skip to content
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

Machine readable precondition failure information #816

Closed
john-conti opened this issue Sep 12, 2022 · 2 comments · Fixed by #858
Closed

Machine readable precondition failure information #816

john-conti opened this issue Sep 12, 2022 · 2 comments · Fixed by #858
Assignees
Labels
area/api v1 Affects the v1 API area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) hint/good first issue Someone new could handle this priority/2 medium This needs to be done

Comments

@john-conti
Copy link

Currently when a precondition fails I see a GRPC response with FAILED_PRECONDITION, received into my application as a io.grpc.StatusRuntimeException:

Caused by: io.grpc.StatusRuntimeException: FAILED_PRECONDITION: failed precondition: relation/permission `foo` not found under definition `site`

On my project we'd like to be able to use machine readable data to synthesize higher level (schema-aware) error messages on our output, without parsing the GRPC Description string returned by StatusRuntimeException.getDescription(). We were wondering if the metadata key/value pairs could be used to parameterize the response with a precondition type, and the specific parameters to the precondition that failed. In the above we'd want to know that the precondition type was checking for the existence of a relation/permission, that the parameter for the check was "foo" and the definition it was expected in was "site". Maybe something like the following:

precondition_type: RELATION_EXISTENCE
relation_permission_id: foo
object_definition: site

This level of request and response would likely be easy to implement, but the current errors do not appear (and I might be mistaken on this) to be able to always unambiguously indicate which precondition failed in the case that multiple preconditions have been sent, or multiple sent and internal preconditions fail, possibly referring to the same definitions, objects, subjects, etc. So part of this request might involve enhancing internal error propagation to enable the returned metadata to always indicate, in a machine-readable way, exactly which instance of a precondition failed.

@josephschorr josephschorr added priority/2 medium This needs to be done area/api v1 Affects the v1 API area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) hint/good first issue Someone new could handle this labels Sep 12, 2022
@josephschorr
Copy link
Member

@john-conti Definitely doable.

Most errors raised within SpiceDB are well-typed. For example: https://github.com/authzed/spicedb/blob/main/internal/dispatch/graph/errors.go. There are some that are not, but it would be fairly straightforward to add the remainder.

Then the error converters would be modified to include the metadata. Example: https://github.com/authzed/spicedb/blob/main/internal/services/v1/relationships.go#L358

josephschorr added a commit to josephschorr/spicedb that referenced this issue Sep 20, 2022
@josephschorr josephschorr self-assigned this Sep 30, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Sep 30, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Sep 30, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Sep 30, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Oct 4, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Oct 4, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Oct 4, 2022
josephschorr added a commit to josephschorr/spicedb that referenced this issue Oct 6, 2022
@john-conti
Copy link
Author

This is fantastic. Looking forward to a test spin soon. 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api v1 Affects the v1 API area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) hint/good first issue Someone new could handle this priority/2 medium This needs to be done
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants