Asking rather than reporting, because I may be misreading either the schema or the intent — and if the answer is "deliberate, for now", that is a useful thing to have written down.

What I observed

disabled-boolean-flag from flagd-testbed:v3.8.0, over OFREP:

$ curl -s -X POST localhost:8016/ofrep/v1/evaluate/flags/disabled-boolean-flag -d '{"context":{}}'
{"key":"disabled-boolean-flag","reason":"DISABLED","metadata":{}}     HTTP 200

The application receives the code default value with errorCode = FLAG_NOT_FOUND.

Why I think it might be unintended

evaluationSuccess in open-feature/protocol's service/openapi.yaml requires only key and reason. value is not required, because one member of its oneOf is codeDefaultFlag:

Note: This schema has no value property. The provider must use the code default value when processing this response.

DISABLED is in that schema's reason enum, so the response above looks well-formed to me: a successful evaluation that defers to the code default.

In Resolver.java (~174-181), handleResolved appears to take its responseValue == null branch and return the code default with FLAG_NOT_FOUND, discarding the reason parsed a few lines earlier. If that reading is right, the effect is not limited to disabled flags — any codeDefaultFlag response would reach the application as a failure error code on an evaluation that succeeded.

Questions

1. Is codeDefaultFlag support intended for this provider, or knowingly out of scope for now? code default flag support landed in the protocol in protocol#49 (2025-08-21) as a breaking change, and I could not find any issue in the org tracking provider-side adoption of it — so "nobody has got to it yet" seems at least as likely as "this is a bug".
2. If it is in scope: is FLAG_NOT_FOUND deliberate here? I would have expected no error code at all, with the reason from the response passed through.
3. Is there a reading of the schema under which the current behaviour is correct and I have this backwards?

How I ran into it

Building the cross-language provider conformance suite proposed in open-feature/spec#417. A new gated @disabled-flags capability asserts that a flag disabled in the management system resolves to the code default. Four scenarios fail here, all on the error-code assertion — the value assertion passes, because the provider does fall back to the default on error, so the value looks right while the error code says the evaluation failed.

For calibration, the same scenarios pass against the Go and JavaScript OFREP providers, which is what made me think this is worth asking about rather than a limitation of OFREP itself. I am not attached to any particular answer here.

Since filing (2026-10-20)

• A second backend reproduces it. The GO Feature Flag relay proxy answers a disabled flag the same way, {"reason":"DISABLED"} with no value. The Java GO Feature Flag provider's remote mode delegates to this provider and fails the same 5 scenarios (test(go-feature-flag): adopt the OpenFeature Provider TCK #1947). Its in-process mode passes them, against the same backend.
• Question 3 has an answer. OFREP's ADR-0006 says that when a response uses codeDefaultFlag, providers MUST use the code default value, with key, reason, variant and metadata unchanged. So an error code here is not a permitted reading.
• Go passes only partly by design. Its resolvers check reason == DISABLED rather than a missing value, so a value-less success with any other reason would still fail there.