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
- 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".
- 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.
- 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.
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-flagfromflagd-testbed:v3.8.0, over OFREP:The application receives the code default value with
errorCode = FLAG_NOT_FOUND.Why I think it might be unintended
evaluationSuccessinopen-feature/protocol'sservice/openapi.yamlrequires onlykeyandreason.valueis not required, because one member of itsoneOfiscodeDefaultFlag:DISABLEDis in that schema'sreasonenum, so the response above looks well-formed to me: a successful evaluation that defers to the code default.In
Resolver.java(~174-181),handleResolvedappears to take itsresponseValue == nullbranch and return the code default withFLAG_NOT_FOUND, discarding thereasonparsed a few lines earlier. If that reading is right, the effect is not limited to disabled flags — anycodeDefaultFlagresponse would reach the application as a failure error code on an evaluation that succeeded.Questions
codeDefaultFlagsupport intended for this provider, or knowingly out of scope for now?code default flag supportlanded 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".FLAG_NOT_FOUNDdeliberate here? I would have expected no error code at all, with thereasonfrom the response passed through.How I ran into it
Building the cross-language provider conformance suite proposed in open-feature/spec#417. A new gated
@disabled-flagscapability 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.