When cache.Once is called with a Redis dropped connection it does not fail
Opened this issue · 3 comments
Redis Cache version: v8 (last available).
Redis version: v8 (last available).
OS: Mac OS.
When you call Once after the Redis connection is lost, the return err is nil. After some debugging, it seems that somehow the "redis: client is closed" error is being masked by the internal caller.
The same call for Get, Set, etc. gets an error, describing the client is closed situation.
Please check this gist (with a main program) which demonstrates the bug:
https://gist.github.com/datoga/cb31c8ee1ae540dcd64cb956dfecc9a1
That is expected. If Redis is down, cache will call the underlying function to get the result and discard the error from Redis.
what's the suggestion for leverage Once or other function provided to figure out whether there is a problem communicating with Redis during cache get/set? apparently this doesn't work even when SkipLocalCache is explicitly set to false..
If Redis is down, but we still have the ability to get the data from somewhere else, it makes sense to do it and fail gracefully. This delivers additional robustness to have this fail-proof mode. There will be an expensive call to populate the cache on every Once call, but at least the client will get something at the expense of the performance of having a functional Redis. It makes little sense to return only an error if there is a way to get the data from somewhere.
However, silently swallowing an error is making it hard to detect if Redis is down, especially if the system has only Once calls and does not have any other function calls that fail on Redis being down.
Is it possible to make Once return a specific error that can be unwrapped AND populating the data/payload to handle this failure and distinguish the Redis error from simply not having an item in cache?