Ways to handle backend downtime.

[simon-liebehenschel]

Case: Redis is unavailable.

Long time ago I had my own decorator that looked similar to (pseudo-code):

try:
    return redis.get(key)
except RedisError:
    # Cache is unavailable, so recalculate 
    result = func()
    try:
        redis.set(key, result)
    except RedisError:
        # Ignore Redis errors and continue
    return result

Question: how can I handle Redis downtime with "cashews"? Or I must to create a second Redis server that will be used as a fallback?

[simon-liebehenschel]

It seems that I can import

from cashews.decorators.cache.defaults import _empty

and return this _empty from GET/SET methods in my Redis class.

FIY: I overwrite your Redis class (I inherit from it to create a new class). Also, I directly import "cashews" decorators and I pass my custom Redis class into imported decorators.

[simon-liebehenschel]

@Krukov How do you handle Redis problems? E.g. redis.exceptions.TimeoutError. What if we will update decorators (optionally) to run a decorated function if a backend is unavailable?

[Krukov]

Good question. Originally cashews was designed for mostly using decorators api and the problem with connection errors handlering fully covered by configuration

Any connections errors are suppressed, to disable it use safe=False

But now we can see that a Basic api quite popular too. And I missed this problem with connections error in the design of basic api.
Now I only can offer you to set safe=False and catch exception from redis.exceptions module