splitrb
Concurrency issues when entering trials
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: https://github.com/splitrb/split/blob/d3ef9d79d2fe15d95292072420e62afea151dffd/lib/split/trial.rb#L71
With a matching write here: https://github.com/splitrb/split/blob/d3ef9d79d2fe15d95292072420e62afea151dffd/lib/split/trial.rb#L83
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.
Hey @wheeyls, thanks for bringing this up.
Indeed, mixing concurrency/writes/reads without some kind of locks may lead to inconsistency.
Probably most users of Split are using Redis as a default for persistence, but as it's possible to create custom adapters too. So we'd need a way to not couple the solution with Redis or any other database. But still, be able to implement a lock mechanism.
In the meantime I'm planning a refactor around Split::Trial, maybe I can think of something on the way.
