Condition assignment sometimes stalls out

[emilyliquin]

Lots of people (at least 100) started a study all within a minute or two of each other. The way the condition assignment works is that it reads which condition has the lowest number of participants, then it assigns the participant to that one (to keep condition assignment balanced). BUT if the number of participants has changed in the time it takes to read the conditions and attempt to assign the participant, it will retry. It will keep retrying until one of two things has happened: (1) the numbers in the database are stable in the time it takes to read/write, or (2) 4.5 minutes has elapsed. I think what might have happened is that it was still retrying, because 4.5 minutes hadn’t elapsed and the numbers hadn’t stabilized (because there were so many people the condition counts kept changing). My study is pretty short, so they got to the point in the study where the condition assignment became relevant before the 4.5 minutes was up. This would mean (1) no errors from the transaction assigning condition, because it was still ongoing, but (2) errors from the code that requires condition, because it hasn’t been set yet.

Solution to implement: Retry transaction for a shorter amount of time, and then fallback to assigning truly randomly (rather than balanced random)? And maybe do a check when condition variabless are used to ensure that they've been set.

[emilyliquin]

In theory c601d19 fixes this issue, but needs to be tested

[emilyliquin]

still unresolved: if existing firestore conditions counter doesn't use the distributed shards thing, it doesn't work (only works for creating new one)