The "choose trial" logic is not atomic, so it is easy to run it multiple times for the same user.
Specifically, there is a read here:
|
self.alternative = @user[@experiment.key] |
With a matching write here:
|
@user[@experiment.key] = alternative.name if !@experiment.has_winner? && should_store_alternative? |
With no lock around these reads and writes, it is very easy to get into a situation where this code runs simultaneously on different processes, and puts the user in a strange state.
When using cookies, I don't think there is a solution for this that will be stable. But when using Redis for persistence, it should be possible to be consistent in a concurrent environment.
Honestly after looking into this, I'm not sure that is a problem worth solving for my use case. That's why this is an issue and not a PR, just wanted to capture this problem so it can be discussed.
The "choose trial" logic is not atomic, so it is easy to run it multiple times for the same user.
Specifically, there is a read here:
split/lib/split/trial.rb
Line 71 in d3ef9d7
With a matching write here:
split/lib/split/trial.rb
Line 83 in d3ef9d7
With no lock around these reads and writes, it is very easy to get into a situation where this code runs simultaneously on different processes, and puts the user in a strange state.
When using cookies, I don't think there is a solution for this that will be stable. But when using Redis for persistence, it should be possible to be consistent in a concurrent environment.
Honestly after looking into this, I'm not sure that is a problem worth solving for my use case. That's why this is an issue and not a PR, just wanted to capture this problem so it can be discussed.