If batches are queued, open waitroom when previous batch is done.

[i-gao]

Currently, if two batches are queued, the second waitroom opens immediately upon the first one starting. The issue is that the batch doesn't actually start until the previous batch has finished. Even if we have enough people ready, they have to wait at least an hour for the previous batch to complete. We're losing a lot of people due to frustration over this wait time. We need either a) the batches to run concurrently or b) the second batch to not accept people until the first one is almost done (say, on the last round).

[deliveryweb]

batch doesn't actually start until the previous batch has finished

Are you sure? I don't see any code logic like this. We can have a lot of ACTIVE batches at 1 moment.

[i-gao]

Hmm I see. What I've observed is that around 5 minutes into the first batch, the second one gets enough users, but the batch doesn't start. If it's not because the batch isn't active, then it's because people haven't pressed Join Batch.

Could you check the logs for batch 5d236fed5763bb73bd089688? Did the failure to roll over occur because not enough people clicked the "Join Batch" button?

[deliveryweb]

It has 3 users now (it means 3 users in moment of stop). It needs 9 users to start, because team size is 3. Start cannot be failed because of small number of people clicked the "Join Batch" button - because this is start condition. 9 users clicked -> start batch.

[deliveryweb]

if (batch.users.length >= batch.teamSize ** 2 && batch.status === 'waiting') { //start batch clearRoom(batch.preChat, io); await startBatch(batch, socket, io) }