-
Notifications
You must be signed in to change notification settings - Fork 155
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
Flakiness: TestRedLock.test_locking_dogpile[memcached_cache] #587
Comments
test_cached_stampede[memcached] is also flaky. I suspect it's the same issue. |
Do you think this is a problem with memcached only, or would happen with redis as well? Am considering using the lib with redis. |
redis tests aren't failing randomly, only memcached is causing issues. |
Ok thanks, I now see that you did mention "only with the memcached backend" already right at start, but maybe it didn't hurt to confirm. I made a branch yesterday where copied the dogpile solution from this test to our cache decorator, am planning to put it to production soon, after some more testing. |
Often getting this test failure in the CI (only with the memcached backend):
It seems like the most likely cause to me is that on some race condition 2 calls to
client.add()
succeed, resulting in 2 coroutines entering the lock at the same time. In theory, only one call should be possible to succeed, the other should error because the key already exists. If this is caused by the memcached backend, then maybe we need to do something to work around it and provide a better guarantee that the lock works as expected.The text was updated successfully, but these errors were encountered: