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
Add ability to wrap errors returned by custom built-in functions #5890
Comments
As you mentioned you could encode all the necessary context from your custom error in it's |
Retrieving that information from the An example use case is whenever the custom error information needs to be serialized, e.g. as part of a response from an HTTP server. It may be possible to recover this data from the error string, but it would involve serializing the custom error information in It would be convenient to be able to retrieve the error data using Go's error wrapping idiom if it's feasible to extend |
It seems to me the caller should be able to handle the roundtrip given the Error method is defined by the plugin author. It would still be interesting to know what wrapping idiom you are referring to here. |
The caller can retrieve that information from the returned error string, but the string needs to be parsed according to how it's formatted internally by OPA. Can we rely on this format not changing? Specifically, I'm talking about the following method that finalizes built-in method calls: https://github.com/open-policy-agent/opa/blob/main/rego/rego.go#L2576 The idiom I'm referring to is the wrapping functionality introduced in Go 1.13 that allows nested errors to be retrieved: https://go.dev/doc/go1.13#error_wrapping |
|
I suppose it would be possible to have unwrap functionality added to the topdown error without breaking existing code. It might be easiest to discuss a PR, at least as a draft? |
OPA currently doesn't support wrapping errors returned by builtin functions. This change modifies topdown.Error to include a wrapped error so that additional context about the builtin error is available. Fixes open-policy-agent#5890 Signed-off-by: Ajith Subramanian <ajithsub@gmail.com>
OPA currently doesn't support wrapping errors returned by builtin functions. This change modifies topdown.Error to include a wrapped error so that additional context about the builtin error is available. Fixes open-policy-agent#5890 Signed-off-by: Ajith Subramanian <ajithsub@gmail.com>
OPA currently doesn't support wrapping errors returned by builtin functions. This change modifies topdown.Error to include a wrapped error so that additional context about the builtin error is available. Fixes open-policy-agent#5890 Signed-off-by: Ajith Subramanian <ajithsub@gmail.com>
OPA currently doesn't support wrapping errors returned by builtin functions. This change modifies topdown.Error to include a wrapped error so that additional context about the builtin error is available. Fixes open-policy-agent#5890 Signed-off-by: Ajith Subramanian <ajith_subramanian@trimble.com>
Thanks for the feedback. I've submitted a draft PR with a first pass of changes required to support this: #5909 |
This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue. |
OPA currently doesn't support wrapping errors returned by builtin functions. This change modifies topdown.Error to include a wrapped error so that additional context about the builtin error is available. Fixes open-policy-agent#5890 Signed-off-by: Ajith Subramanian <ajith_subramanian@trimble.com>
What is the underlying problem you're trying to solve?
I'd like to be able to retrieve a specific
error
object that's bubbled up from the return value of a custom built-in function during evaluation. This would help in cases where relying on theMessage
field oftopdown.Error
doesn't give enough context about how to handle the error returned from policy evaluation originating from a custom built-in function.Currently, errors returned by built-ins have their messages formatted in the
topdown.Error.Message
field inrego.finishFunction
. If the built-in function returns a a customerror
type that contains more contextual information about the error in its fields, this information is either lost or only available through the string representation in theMessage
field.Describe the ideal solution
An example of what I would like to be able to do:
This could be possible if an
Unwrap
method and an additionalerror
field is added totopdown.Error
so that the wrapped error can be retrieved. However, I'm not sure how feasible or far-reaching that change would be to other API/SDK methods that rely ontopdown.Error
.The text was updated successfully, but these errors were encountered: