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

Clarification of reason for evaluation detail and evaluation. #236

Closed
kinyoklion opened this issue Jan 25, 2024 · 2 comments · Fixed by #239
Closed

Clarification of reason for evaluation detail and evaluation. #236

kinyoklion opened this issue Jan 25, 2024 · 2 comments · Fixed by #239
Assignees
Labels
question Further information is requested

Comments

@kinyoklion
Copy link
Member

kinyoklion commented Jan 25, 2024

In the specification it is detailed that the reason is an optional string, and there are a set of pre-defined values, but I do not think it is clear that free-form values are intended to be supported as well. This has resulted in some SDK development which restricts the reason to an enumeration and prevents conveying reasons more specific to the vendor.

A current example of this in the python SDK: https://github.com/open-feature/python-sdk/blob/d1f27e3278964c2d81b780db97deace87d02cae1/openfeature/flag_evaluation.py#L21

(A different issue will be opened for that specific instance.)

@thomaspoignant
Copy link
Member

thomaspoignant commented Jan 27, 2024

In the spec it is mentioned :
Screenshot 2024-01-27 at 11 40 51

I find it explicit that it can be any string, especially if we compare with error code that links to the enum.
Screenshot 2024-01-27 at 11 41 57

I guess the source of error may be to have the table with the pre-defined reason, we can maybe add a note to be explicit that it is extensible 🤔 ?

Screenshot 2024-01-27 at 11 43 36

@toddbaert
Copy link
Member

I agree this could be clearer. Not sure what the best path forward is generally, and per SDK in terms of how to communicate that. I like to thing of these something like HTTP status codes; where a limited set is provided but additional custom codes are permitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants