Set context during provider registration when using the static-context paradigm

[beeme1mr]

Overview

When an SDK follows the static-context paradigm, an update to context may lead to an expensive async operation. For that reason, it's recommended to set known context prior to setting the provider. If the context is set later, even immediately after initialization registration, another call to async call may be made.

Set context before set provider

In this scenario, one call is made to the provider during initilzation.

await OpenFeature.setContext({ browser: "chrome" });
await OpenFeature.setProvider(new MyProvider());

Set context after set provider

In this scenario, two calls may be made to the provider because the context changes after initialization.

await OpenFeature.setProvider(new MyProvider());
await OpenFeature.setContext({ browser: "chrome" });

Proposal

await OpenFeature.setProvider(new MyProvider(), { browser: "chrome" });

The proposal would ensure that context is available to the provider during initialization. Context can still be updated using OpenFeature.setContext() if necessary, but this would help users avoid unnecessary delays during start up.

Requirements

• Define the requirements for setting context during provider registration when using the static-context paradigm

Dependencies

• Manage context per named provider when using the static-context paradigm #218

References

• https://cloud-native.slack.com/archives/C0344AANLA1/p1698431797080439

[toddbaert]

Is there any reason this couldn't be added to both paradigms? It's less important for server, but I don't think it adds too much complexity.

[lukas-reining]

Is there any reason this couldn't be added to both paradigms? It's less important for server, but I don't think it adds too much complexity.

Think so too, for the server this could just be a little convenience.

[beeme1mr]

I'll work on adding this to the spec. In the meantime, here's how it should work in JavaScript.

open-feature/js-sdk#749