-
Notifications
You must be signed in to change notification settings - Fork 1
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
feat: Initialisation strategy #58
Conversation
vahidlazio
commented
Sep 4, 2023
- Add the option to choose an initialisation strategy
- ActivateAndFetchAsync or FetchAndActivate are the different strategies that can be selected in the initialisation phase
e2e3299
to
1dafbc1
Compare
@@ -54,14 +58,43 @@ class ConfidenceFeatureProvider private constructor( | |||
eventsPublisher.publish(OpenFeatureEvents.ProviderReady) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should to send ProviderError
if the cache is empty at this point? Or ProviderStale
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this exception happens when the network request has failed. especially when the initialisation strategy is activate and fetch IMO it doesn't make sense to have provider not ready. for fetch and activate, maybe .. but is it what we want? considering that if the developer decides to have the strategy as "try to refresh first" or "force refresh first"? in the latter case they can't use the properties since the provider is never ready. they will be stuck. but if the definition of FetchAndActivate is try to fetch, then the failure in the network request should be treated as ready? we have to add this to the documentation anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, with ActivateAndFetch, the provider should be ready, since the developer would most likely apply the flags that were fetched later in the lifecycle / next session.
For fetchAndActivate - would we then handle an error as "nothing new to fetch" and wait for another opportunity to fetch freshest flags? In that case, I also agree that it can be a ProviderReady. My only concern (which might come from me not fully understanding Confidence/data science) is whether we report these events correctly.
Provider/src/main/java/dev/openfeature/contrib/providers/ConfidenceFeatureProvider.kt
Show resolved
Hide resolved
Provider/src/main/java/dev/openfeature/contrib/providers/ConfidenceFeatureProvider.kt
Show resolved
Hide resolved
Provider/src/main/java/dev/openfeature/contrib/providers/ConfidenceFeatureProvider.kt
Outdated
Show resolved
Hide resolved
Provider/src/main/java/dev/openfeature/contrib/providers/ConfidenceFeatureProvider.kt
Show resolved
Hide resolved
Provider/src/main/java/dev/openfeature/contrib/providers/cache/StorageFileCache.kt
Outdated
Show resolved
Hide resolved
d27221f
to
4c9ff2f
Compare
Signed-off-by: vahid torkaman <[email protected]>
…orks Signed-off-by: vahid torkaman <[email protected]>
…f disk storage is not empty to set a dynamic strategy
4c9ff2f
to
197bb5e
Compare