[ ENHANCEMENT ] Automatically randomize queue

[xia-steven]

Would be nice if there was an option to automatically randomize the queue order for the first x seconds after queue opens for students with the same priority. The current system completely messes up priority from our testing with 482 staff.

[CarsonHoffman]

There's a couple considerations here:

1. The queue is built on a stateless model, where it simply checks whether the queue is open or not when a request is made; there isn't any mechanism for executing an event x seconds after it opens.
2. Ordering is only currently possible by timestamp or by priority, which is why I implemented the randomization using the priority feature. We don't currently have a way to arbitrarily order entries in the queue. I agree that it can mess with the first-of-the-day priority system, but this is simply a tradeoff I had to make when enabling the randomization at all. If you're trying to both use randomization and the first-of-the-day bonus, I'd recommend randomizing early in the queue cycle so that everybody equally loses their advantage. 😛

I don't think that either of these limitations are likely to change in the near future—they're pretty fundamental to the queue's design, and would require major overhauls to re-tool.

[developStorm]

we can probably try to assign priority by normalizing the time and manipulate the millisecond part of time (then we have 1000 slots to use which should be decent).

And since OH queue has ELK the original time of entry will be kept in log system and can be exported normally in the full queue log (if few seconds of inaccuracy matters at all

[CarsonHoffman]

The main issue with that is that the timestamp is derived from the ID. We can't freely manipulate the timestamp; it's baked in. (Changing the ID is a non-starter for a ton of reasons; it's the unique identifier of a queue entry.)

[developStorm]

This idea is now getting even crazier - for entries added to the queue in the first x seconds, randomize their timestamp millisecond portion with a fixed seed after each derivation of the timestamp? This happens every time when queue entires endpoint is requested

Not sure how feasible this is, but a fixed seed (which could be a queue opening timestamp, for example) ensures that the random millisecond generated is fixed each time, while eliminating the need to store more state. This would also allow for automatic randomisation as a side effect.

Well totally fine if this is not possible. Even if this could be implemented, the actual code might not seem to make much sense.