Unstable ETag because of hash rantomisation

[dvarrazzo]

Python hash() function is salted by default (see hash docs). Therefore the hash of the same object doesn't normally produce the same value in different processes.

As a result, because of the way ETags are produced, the cache gets invalidated when the service restarts. Or, if the service is deployed with more than one backend behind a load balancer, every backend will return a different etag for the same resource, making it useless.

fastapi-cache/fastapi_cache/decorator.py

Line 201 in 91ba6d7

"ETag": f"W/{hash(to_cache)}",

As a workaround, setting PYTHONHASHSEED to a fixed value disables hash randomization.

[vicchi]

@dvarrazzo I'm torn between this being categorised as a bug or an enhancement as it will change the behaviour of the cache, albeit in a good way. So I've gone for an enhancement and flagged this for inclusion in the next release.

[ermiyaeskandary]

Facing this and voting +1 for it to be a bug as this makes the cache unusable on larger-scale load balanced applications.