Problem
When Redis is down, @cache fails open as documented, but each cached request takes about 7.4 s. redis-py 8's default Retry (several retries with exponential backoff) makes each get and set take about 3.7 s before the error reaches the library:
GET /x -> 200 in 7.40 s (Redis unreachable)
AppCache.get -> 500 in 3.83 s
Passing retry=Retry(NoBackoff(), 0) through the backend's **kwargs brings it back to about 0 s. Neither "When the backend fails" (HTTP_CACHING.md) nor BACKENDS.md mentions this, so "fail open" still looks like an outage.
Proposal
- Document the retry and timeout settings (
retry=, socket_timeout, socket_connect_timeout) next to fail-open, with an example.
- Consider a smaller default retry budget in
AsyncRedisCacheBackend when the caller passes none. That would be a behaviour change, so it needs a note in the changelog.
- A circuit breaker could follow later as a separate issue.
Problem
When Redis is down,
@cachefails open as documented, but each cached request takes about 7.4 s. redis-py 8's defaultRetry(several retries with exponential backoff) makes eachgetandsettake about 3.7 s before the error reaches the library:Passing
retry=Retry(NoBackoff(), 0)through the backend's**kwargsbrings it back to about 0 s. Neither "When the backend fails" (HTTP_CACHING.md) nor BACKENDS.md mentions this, so "fail open" still looks like an outage.Proposal
retry=,socket_timeout,socket_connect_timeout) next to fail-open, with an example.AsyncRedisCacheBackendwhen the caller passes none. That would be a behaviour change, so it needs a note in the changelog.