tl;dr: the default set_provider() / recommended way to initialize should be non-blocking. Blocking-by-default may lead to hard-to-debug denial of service.
Requirement 1.1.2.4
The API SHOULD provide functions to set a provider and wait for the initialize function to complete or abnormally terminate.
This function not only sets the provider, but ensures that the provider is ready (or in error) before returning or settling.
// default provider
OpenFeatureAPI.getInstance().setProviderAndWait(myprovider); // this method blocks until the provider is ready or in error
// client uses the default provider
Client client = OpenFeatureAPI.getInstance().getClient();
// provider associated with domain-1
OpenFeatureAPI.getInstance().setProviderAndWait('domain-1', myprovider); // this method blocks until the provider is ready or in error
// client uses provider associated with the domain named 'domain-1'
Client client = OpenFeatureAPI.getInstance().getClient('domain-1');
Requirement 1.1.2.4 implies that the default set_provider() should not wait for the provider to initialize.
Having the waiting implementation being the default has a couple of issues. The recommended api.set_provider(MyProvider()) blocks the rest of the application from proceeding. This turns a provider hanging during initialization into an application denial of service.
This can be exaggerated further by something like gunicorn which has an default 30s worker initialization timeout. If the provider takes 30+ seconds to initialize, this leads to gunicorn killing the worker with a cryptic WORKER TIMEOUT message which may be hard to debug.
If set_provider() is non-waiting, the worst case scenario is evaluations returning default values which is much safer. For users who do want to wait, we should provide set_provider_and_wait()
tl;dr: the default
set_provider()/ recommended way to initialize should be non-blocking. Blocking-by-default may lead to hard-to-debug denial of service.Requirement 1.1.2.4 implies that the default
set_provider()should not wait for the provider to initialize.Having the waiting implementation being the default has a couple of issues. The recommended
api.set_provider(MyProvider())blocks the rest of the application from proceeding. This turns a provider hanging during initialization into an application denial of service.This can be exaggerated further by something like gunicorn which has an default 30s worker initialization timeout. If the provider takes 30+ seconds to initialize, this leads to gunicorn killing the worker with a cryptic
WORKER TIMEOUTmessage which may be hard to debug.If
set_provider()is non-waiting, the worst case scenario is evaluations returning default values which is much safer. For users who do want to wait, we should provideset_provider_and_wait()