If a backing service sends me 200 with error message in the body..

[monikma]

Yes, this is bad API design of theirs, but I just came across such situation an a foreign API that I am using. And this is actually an unexpected error on their side that comes and goes (actually comes quite often). This means that while using cachedRequest (or request too) sometimes I end up inside "success" case, even though the body says that there was an unexpected error.. and as the request becomes cached (haha, as it was 200 response), I cannot escape this error anymore, without deleting the entire cache directory.. not very handy..

Is there any workaround recommendation? Any feature of invalidating the cache for certain request? This would be really useful for me at the moment.. I know I could set ttl to lower value, but that would remove most of the benefits of using this library for me (now my ttl is 24 hours..).

[danypype]

I have one suggestion. It sounds like you need caching to happen in front of your logic, not in the middle (not what cached-request does.) If the API you are consuming is masking errors inside successful responses, you wont get much from using cached-request or any other middle-ware for caching. You need a front-cache, also a front error handler. In other words, you should be caching after making sure the successful response doesn't contain any hidden error.

If you want to have middle-ware caching, because you like good code design, I just had this crazy idea of making cached-request able to handle filters, maybe a pipeline of post-response filters that trigger in order after every response. So please feel free to contribute; README.md is a good file to start with, just write your ideas down and submit a Pull Request, then we can go from there. :)

[danypype]

@monami555 Take a look at requestify as an alternative to request + cached-request; it has the option to purge a given response from the cache.