Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification on provider init #99

Closed
philipp-schmidt opened this issue Oct 21, 2024 · 4 comments
Closed

Clarification on provider init #99

philipp-schmidt opened this issue Oct 21, 2024 · 4 comments

Comments

@philipp-schmidt
Copy link

According to the specification, a provider can implement an init function.

For the flagd provider, I expected this to connect to flagd via grpc and throw an exception if no connection could be established. This is currently not the case.

My next guess was that the provider state would be != ProviderState.READY, but that's not the case either.

The first time any form of error is indicated is on first flag evaluation:

FlagEvaluationDetails(flag_key='feature-flags-enabled', value=False, variant=None, flag_metadata={}, reason=<Reason.ERROR: 'ERROR'>, error_code=<ErrorCode.GENERAL: 'GENERAL'>, error_message='received grpc status code StatusCode.UNAVAILABLE')

The OpenFeature ecosystem seems to be quite young, so it is hard to fully grasp what the specification means by just looking at examples or reading the provider code. Could someone clarify when exactly a provider should indicate an error if no network connection could be established?

On init? After init in the provider state? As emitted event? On flag evaluation?

If this is up to the provider to decide, then also: how does the flagd provider handle it?

Would be very much appreciated!

@philipp-schmidt
Copy link
Author

philipp-schmidt commented Oct 21, 2024

As reference, this is the code currently:

from openfeature import api as openfeatureapi
from openfeature.provider import ProviderStatus
from openfeature.contrib.provider.flagd import FlagdProvider

# Connect to the flagd server
openfeatureapi.set_provider(FlagdProvider(host="127.0.0.1"))
flags = openfeatureapi.get_client()
# Check if provider is ready
provider_status = flags.get_provider_status()
print(provider_status)
if provider_status != ProviderStatus.READY:
    raise ApplicationError(f"Flagd provider is not ready, status: {provider_status}")

test = flags.get_boolean_details("feature-flags-enabled", False)
print(test)

I'm testing this with no flagd service running and get the above result.

@philipp-schmidt
Copy link
Author

philipp-schmidt commented Oct 21, 2024

I ended up testing the reason field against Reason.STATIC for all evaluations and forcing a flag evaluation on first init of the client to test connectivity once.

Happy to discuss if this is the intended usage of the API in case of the application being designed to never continue with default flag values.

@philipp-schmidt
Copy link
Author

With GRPC doing a network call (probably HTTP?) on each flag evaluation and never keeping a connection up longer than that, it makes perfect sense that there is nothing in the init of the provider which would initially indicate any other state than READY. Also there is never a reason to switch state to STALE or ERROR, everything is stateless. Also there is currently no caching going on which would require any internal state. The current implementation matches this, so it all makes sense now.

@beeme1mr
Copy link
Member

Hey @philipp-schmidt, the flagd provider for Python only supports RPC mode. As you mentioned, it's a basic implementation that's stateless. There's a PR open to adding an in-process evaluation mode, but it isn't actively being worked on at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants