Closed kinyoklion closed 10 months ago
In the spec it is mentioned :
I find it explicit that it can be any string, especially if we compare with error code
that links to the enum.
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 🤔 ?
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.
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.)