Return structured errors from the selectors API #3998
Conversation
| @@ -38,8 +39,110 @@ var ( | |||
| // ErrResultUnknown is returned when the result of a selector expression is unknown | |||
| // this tells the caller to try again with more information | |||
| ErrResultUnknown = errors.New("result is unknown") | |||
| // ErrUnsupported is returned when the entity type is not supported | |||
| ErrUnsupported = errors.New("unsupported entity type") | |||
There was a problem hiding this comment.
This error will be easier to test once we expose the errors through handlers
| var jsonString string | ||
|
|
||
| if errors.As(err, &ce) { | ||
| jsonString = ce.Error() |
There was a problem hiding this comment.
This might look like an odd test because go code could very well just look at the contents of the struct, but the thinking was to include the JSON representation as HTTP body when manipulating selectors from handlers throws an error, then FE would be able to parse the JSON which would include the location of the failed CEL expression.
Is that an acceptable pattern or would we prefer to add an error message to the protobuf message?
| ErrDetails: errDetailsFromCelIssues(source, issues), | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
should these errors wrap a common one to ease error handling? https://pkg.go.dev/errors you could implement Unwraps for this.
There was a problem hiding this comment.
that's a really good idea!
There was a problem hiding this comment.
done. We could even use errors.Join(ErrCheckFailed, ErrParse) for parse and join with a check error for the check but I'm not sure if it's worth it.
In order to tell the user what's wrong with a selector they are about to take into use, let's introduce a structured way of returning errors to the selector API. The errors can be represented as JSON in order for clients to be able to parse the error without knowing much about the type.
jhrozek
force-pushed
the
selectors_structured_errors
branch
from
0ef5a6c
to
3f71033
Compare
Summary
In order to tell the user what's wrong with a selector they are about to
take into use, let's introduce a structured way of returning errors to
the selector API.
The errors can be represented as JSON in order for clients to be able to
parse the error without knowing much about the type.
Related: #3725
Change Type
Testing
with the added unit tests and as part of a larger topic branch
Review Checklist: