open-feature / spec

OpenFeature specification
https://openfeature.dev
Apache License 2.0
588 stars 35 forks source link

Clarification of reason for evaluation detail and evaluation. #236

Closed kinyoklion closed 4 months ago

kinyoklion commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.