-
Notifications
You must be signed in to change notification settings - Fork 3
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
docs: Spec putContext / track(ConfidenceContextProducer) #175
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Nicklas Lundin <[email protected]>
|
||
In both cases above, any context change triggers a new asynchronous `fetchAndActivate` and the flags in the | ||
local cache are re-evaluated remotely according to the new context: until this background operation is complete, | ||
flag values are returned to the application according to the old context's evaluation, and with `resolveReason = .stale`. |
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.
Here, I would add the following to the Spec:
putContext
is an await-able function, which returns when the flag cache is ready and reflects the newly configured context. When using ConfidenceContextProducer
, the context can change more dynamically and stale
value are to be expected.
Observation 1
From the DemoApp:
The ideal situation would be to have a single
fetchAndActivate
call, and the ability to await an async function to make sure the flags are fresh and ready in the cache. However, our current API portfolio doesn't seem to allow for both of those things together.Observation 2
Code snippet here.
Today it's impossible to have a setup where the context is changed and the UI showing a loading indicator until the resolve is complete, while at the same time having a single
fetchAndActivate
call for each context change.Possible improvements
putContext
is made async: users can wait for the new flags to be ready before reading values (this is probably harder to achieve with the ContextProducer solution)