[FEATURE] Support a means of communicating "use-code-default" and "disabled" without requiring variant/value

[toddbaert]

Problem

There's 2 features we'd like to support in flagd which we require OFREP enhancements for:

• flagd supports DISABLED flags as seen here, but does this by throwing FLAG_NOT_FOUND. Instead, we'd like the user experience to resemble a "successful" evaluation, with code default returned and reason=DISABLED.
• flagd will soon support omitting a defaultVariant, meaning that if targeting does not match, no value is returned; the evaluation would be "successful", code default is returned and reason=DEFAULT.

Neither of these are currently possible in OFREP, because OFREP evaluationSuccess responses require a value and flagd cannot return one here.

Proposed solution(s)

1. Make value in the evaluationSuccess optional, and use a 204 and another 2xx code or similar to indicate that the provider should default gracefully and set the reason appropriately
2. Add additional custom errors to specifically indicate this situation (ex: disabledError and defaultError) which the OFREP provider will catch and use to gracefully default, and set the reason appropriately.

I see either of these as workable, though I have a slight preference for (1).

[lukas-reining]

Hey, sorry I could not make it yesterday night.
I totally understand the need for it so in my opinion, supporting DISABLED with omitted variant and a normal 200 status code would be my preferred solution.

I would not opt for a 204 as this should not have content by the spec:

A 204 response is terminated by the end of the header section; it cannot contain content or trailers.

https://www.rfc-editor.org/rfc/rfc9110#status.204

Also in my opinion, this is still a standard evaluation response, just without a value.

Using this, we can implement single and bulk eval, while sending a 204 with an empty response would require special handling for bulk eval (similar to the proposed solution or omitting disable flags entirely).
Also we would loose the option to return flag metadata, which I think can still be valuable.

To summarize, I would vote for solution 1 without a special HTTP status code.

This would be breaking for the providers, but we could update them before merging a possible spec change.

[beeme1mr]

I'm also in favor of this. I originally thought this wasn't necessary. However, I'm now realizing that not having proper support causes numerous telemetry and flag lifecycle challenges.

I do think we should find a better term than DISABLED. As a user, I would be surprised to see disabled flags included in the response payload. Perhaps we should consider defining a new reason that more clearly matches our intentions.

[toddbaert]

I do think we should find a better term than DISABLED. As a user, I would be surprised to see disabled flags included in the response payload. Perhaps we should consider defining a new reason that more clearly matches our intentions.

I think I disagree with this. DISABLED describes the situation perfectly, and personally if I saw a disabled flag in a payload I would simply assume there's some value in sending it besides evaluating it, which is exactly the case.

[beeme1mr]

I think I disagree with this. DISABLED describes the situation perfectly, and personally if I saw a disabled flag in a payload I would simply assume there's some value in sending it besides evaluating it, which is exactly the case.

After rereading the proposal, it sounds like the server would define the reason, so it would be up to each implementation to decide which reason makes the most sense for their use case.

[toddbaert]

I made a really quick PoC of this in JS: open-feature/js-sdk-contrib#1358, I just threw it together fast making as few refactors as possible to make it easy to understand, but it shows how workable option 1 is, I think.