Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Option to return prior cached value on update failure

See original GitHub issue

We have a case where some network-loaded asset changes rarely, but we need to notice changes to it relatively quickly. Therefore, we use a memoized async function with a maxAge of 10 minutes.

However, if there is a brief network interruption when the item is requested after expiring, this causes an error to be returned and the cached value purged. This makes sense as a default behavior, but it would be nice to be able to opt-in to a behavior that will not purge the cache, but will return the last-cached value when the update function fails (synchronous exception, or returned promise becomes rejected).

In the case of async functions in particular, this may be somewhat complex because there can be two pieces of cached data: the last-resolved value, and a currently-awaiting promise. The desired behavior on a rejection is that the currently-awaiting promise is cleared and the last-cached value is returned instead of the rejected promise, but the item’s age is unaffected, which will cause future fetches to retry immediately. Combined with a low timeout, this allows the application to continue using the last-known value while continually retrying for an updated value.

This is the widely-used “serve stale on error” pattern used by CDNs, applied to this module.

Since this causes errors to be swallowed by the memoized function, the documentation should probably hint that errors within the fetch function should be logged somewhere as they will not be observable otherwise.

Alternatively, there could be some way to communicate via the rejection error object (by error type or a flag on the object) whether the failure should be propagated to the caller or if the last-cached value should be used instead.

One potential way this could be implemented would be to introduce a mechanism by which the update function can be given the last-cached value, which it could choose to return. Combined with the ability for the update function to be able to indicate the TTL of the item (#23) this could easily give users their own way to implement this feature in a more flexible way.