Reduce chances of race conditions when processing deleted toots #9815
Conversation
ClearlyClaire
force-pushed
the
fixes/delete-processing
branch
from
85365c8
to
80f8e6a
Compare
|
Added a commit which uses a lock, ensuring that a deleted status has either been processed or won't be processed at all. I am not too sure about the performance implications when processing |
ClearlyClaire
force-pushed
the
fixes/delete-processing
branch
from
80f8e6a
to
71f4193
Compare
|
|
||
| RedisLock.acquire(lock_options) do |lock| | ||
| if lock.acquired? | ||
| return if delete_arrived_first?(object_uri) |
There was a problem hiding this comment.
CodeClimate complains, but I find it clearer to just return here. Or maybe there's something I don't understand about Ruby blocks?
There was a problem hiding this comment.
I believe the code does what you want it to do, but in most cases return from a block is a mistake.
| @@ -21,11 +21,13 @@ def delete_person | |||
| def delete_note | |||
| return if object_uri.nil? | |||
|
|
|||
| RedisLock.acquire(lock_options) do |lock| | |||
| delete_later!(object_uri) | |||
There was a problem hiding this comment.
CodeClimate complains about us not using lock, but we can't leave it out.
We don't use it because we want to call delete_later! even in the unlikely case where we couldn't acquire the lock, it's not really an issue.
There was a problem hiding this comment.
We can totally leave it out though? Or just name it _lock
There was a problem hiding this comment.
We can't leave it out because Redislock checks for that parameter (see https://circleci.com/gh/tootsuite/mastodon/39022?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link). I will name it _lock.
ClearlyClaire
force-pushed
the
fixes/delete-processing
branch
from
71f4193
to
285a38f
Compare
ClearlyClaire
force-pushed
the
fixes/delete-processing
branch
from
285a38f
to
2fc1ac3
Compare
…odon#9815) * Reduce chances of race conditions when processing deleted toots * Prevent race condition when processing deleted toots
I have noticed that sometimes, toots are not correctly deleted across instances (despite a direct Follow relationship).
One of those cases may be because of a race condition between the processing of
CreateandDeletewhen a toot is quickly created then deleted.This PR reduces chances of such a race condition happening, but does not eliminate it. It should be possible to avoid this race condition completely by moving the
delete_arrived_first?check into the locked block, and lock thedelete_later!call as well, but I'm not sure about the performances impact.