Provider Initialization Fallback

[liran2000]

Problem effect

With this scenario occurs, service applications can have unexpected results, since all flags evaluations returns default value.

Problem description

Scenario

provider service is temporary down during provider initialization.

Result behavior

Since provider feature flags configuration cannot be fetched, all flags evaluations returns default value until provider service is up. Different scenario such as provider service is temporary down during service run is less problematic, since flags evaluation can be done via local feature flags configuration cache.

Provider Initialization Fallback Mechanism - High level solution

Configuration changed/fetched -> save configuration to cache, and also to file / other storage. Provider initialization Error event -> load configuration from the file / storage.

OpenFeature treatment for this scenario

Provider initialization has an initialization Error status, which helps. Since configuration is not directly exposed via OpenFeature, implementing such behavior is vendor specific, and may require additional provider configurations, and there are no guidelines or mentions for provider to handle such scenario.

Initial solution suggestion direction

Idea is that OpenFeature SDK will have this logic out of the box, when the provider implementing the relevant methods.

Spec additions

• The provider MAY define saveConfig function which performs configuration save logic relevant to the provider.
• The provider MAY define loadConfig function which performs configuration load logic relevant to the provider.
• The provider MAY expose config properties to set on the provider before setting it to the OpenFeature client, for using on save/load configuration, such as file location or other storage.

SDK additions

The SDK will call saveConfig on PROVIDER_READY and PROVIDER_CONFIGURATION_CHANGED events, and loadConfig on ERROR initialization status.

Initialization error flow

sequenceDiagram
  participant SDK as SDK (server-side)
  participant features as Features Service
  participant storage as Storage
  note left of SDK: initialize
  rect rgb(30,144,255)
  note left of SDK: OpenFeature method
  end
  SDK->>features: fetch config https://...
  rect rgb(255,0,0)
  features->>SDK: Error status
  end
  rect rgb(30,144,255)
  note left of SDK: new OpenFeature method
  end
  SDK->>storage: loadConfig
  storage->>SDK: OK

Normal flow

sequenceDiagram
  participant SDK as SDK (server-side)
  participant features as Features Service
  participant storage as Storage
  note left of SDK: initialize
  SDK->>features: fetch config https://...
  rect rgb(127,255,0)
  features->>SDK: Feature Flags configuration JSON
  end
  note left of SDK: save config in cache
  rect rgb(30,144,255)
  note left of SDK: new OpenFeature method
  end
  SDK->>storage: saveConfig

Thoughts ?

[beeme1mr]

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.

[thomaspoignant]

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.

[Kavindu-Dodan]

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.

[beeme1mr]

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.