Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unstable ETag because of hash rantomisation #400

Open
dvarrazzo opened this issue Feb 13, 2024 · 1 comment
Open

Unstable ETag because of hash rantomisation #400

dvarrazzo opened this issue Feb 13, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers
Milestone

Comments

@dvarrazzo
Copy link

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.

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

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

@vicchi vicchi added this to the Version 0.3.0 milestone Nov 9, 2024
@vicchi vicchi self-assigned this Nov 9, 2024
@vicchi vicchi added enhancement New feature or request good first issue Good for newcomers labels Nov 9, 2024
@vicchi
Copy link
Collaborator

vicchi commented Nov 9, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants