Skip to content
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

Open
sazzer opened this issue Mar 21, 2024 · 2 comments
Open

Add support for returning last good value #39

sazzer opened this issue Mar 21, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@sazzer
Copy link

sazzer commented Mar 21, 2024

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?

@jhalterman
Copy link
Collaborator

jhalterman commented Mar 25, 2024

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?

@jhalterman jhalterman added the enhancement New feature or request label Mar 25, 2024
@sazzer
Copy link
Author

sazzer commented Mar 25, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants