[Feature Request] make `flag not found` a reason

[piclemx]

Problem

When looking at the output of an evaluation of a boolean flag that doesn't exist, I think it would be preferable that the Flipt API returns that the Flag is false. IMO boolean flag should always consider false by default if nothing is provided.

Ideal Solution

curl --location 'http://localhost:8080/evaluate/v1/boolean' \
--header 'Content-Type: text/plain' \
--data '{
    "flagKey": "patate"
}'

< HTTP/1.1 404 Not Found
< Date: Fri, 05 Apr 2024 18:25:41 GMT
< Content-Type: application/json
< Content-Length: 80
< Connection: keep-alive
< Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src * data:; frame-ancestors 'none'; connect-src 'self' https://app.formbricks.com; script-src-elem 'self' https://unpkg.com;
< X-Content-Type-Options: nosniff
{
	"code": 5,
	"message": "flag \"default/patate\" not found",
	"details": []
}

Would like more something like

< HTTP/1.1 200 Ok
< Date: Fri, 05 Apr 2024 18:25:41 GMT
< Content-Type: application/json
< Content-Length: 80
< Connection: keep-alive
< Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src * data:; frame-ancestors 'none'; connect-src 'self' https://app.formbricks.com; script-src-elem 'self' https://unpkg.com;
< X-Content-Type-Options: nosniff
{
	result: false
        reason: "flag not found"
}

Search

• [X] I searched for other open and closed issues before opening this

Additional Context

No response

[GeorgeMac]

Thanks for the suggestion @piclemx !

My main concern here is that this can lead to confusion if you e.g. miss-spell or miss-reference a flag by mistake. This could easily mislead folks into thinking a flag is present, but disabled/returning false. Then be confused when constraints and targeting rules have no effect on the result of the flag when its in production.

This is at-least the main motivation for flag not found being a fail-fast error. I think this is pretty common in the FF space and e.g. how OpenFeature also handles these evaluation semantics (FLAG_NOT_FOUND is an error code not a reason):

• Reasons: https://openfeature.dev/specification/types#resolution-details
• Errors: https://openfeature.dev/specification/types#error-code

[Chris-Greaves]

I can see where both of you are coming from. I guess it's the job of the Client to handle the FLAG_NOT_FOUND error gracefully.

OpenFeature has a requirement on providers that when 'Resolving' a flag, you have to have a defaultvalue parameter. https://openfeature.dev/specification/sections/providers#requirement-221

I do think this is missing from of the flipt specific client libraries, so I'd stick to the OpenFeature ones.