-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add support for returning last good value #39
Comments
This sounds something like a fallback that caches previous results. One could certainly use a fallback with a function to do something like this today, so we'd have to think about whether this feature is generally useful enough to build into fallbacks. Can you tell me more about a use case for this, so I can get a better sense for it? |
Example use case. System A depends on configuration data that's stored in System B. This configuration data is absolutely cacheable and doesn't change often, but when it does change then it should be reflected quickly. On startup, System A calls out to load the configuration data. It's then set up so that it will cache the data for 20 minutes. 30 minutes later, it's doing something that needs the configuration data but the cache has expired. So it calls out to refresh the data and all is good. 30 minutes later, it's doing something else that needs the configuration data but the cache has expired. So it calls out to refresh the data and System B is offline. Without something like this, System A would now no longer be able to operate until System B comes back. With this, System A can continue with the old, stale version of the data and things continue work. 5 minutes later, it's doing something else that needs the configuration data. The cache has still expired so it calls out to refresh the data and System B is back online. This means that the data is now updated and System A proceeds with the new version instead. |
I'm not sure if this really fits in with the goals for this library, but one potential new policy that could be useful is one that returns the last good value in the case of an error.
The idea being a policy that calls downstream, but on error it instead returns the previously seen successful result, allowing callers to be provided a usable, albeit stale result in cases where that's useful.
Essentially this is the same as Fallback only returning the previous success instead of a hardcoded default value. Potentially it's even just an extension to the Fallback to do this?
The text was updated successfully, but these errors were encountered: