Provider Initialization Fallback about spec HOT 4 CLOSED

Hey @liran2000, thanks for the detailed issue. I think it's important to document the start-up behavior so developers can decide how they would like to handle various failure conditions. It's a goal of the OpenFeature SDK never to break an application. That's one reason the default value is returned if the call to the provider fails. In some situations, this may not be ideal because it could lead to inconsistent behavior across the application. To address this, we could document how a developer could wait for the provider-ready event to fire before starting the application. Unfortunately, this could cause an endless re-creation loop in some environments, but that would be up to the developer to decide the behavior they want.

I don't think OpenFeature should standardize local caching behavior, but I would be interested in others' thoughts. A provider could support caching already without any changes to the spec. It also would be very provider specific because the rulesets and communication vary across tools. I would recommend this stays a provider concern until a reusable pattern emerges.

from spec.

I tend to agree with @beeme1mr, even if having a standard way to manage cache will be helpful for people creating some providers, I am not sure that the needs are similar enough to be standardized by Openfeature.

from spec.

While this is an interesting idea, I see this responsibility to be a part of Provider implementation. As others have highlighted, I also think this is not required to be enforced by the OpenFeature specification. On the other hand, if we need to implement this from SDK itself, then we will need to define a common feature flag configuration structure to use with storage de/serialization. Unfortunately, we do not have such a common structure.

from spec.

This is out of scope for the time being. Please feel free to create documentation or write a blog that would help provider authors better support initialization issues.

from spec.