Many Discord servers make use of a website called "Disboard" to list their servers to the public.
In order to have your server be put higher on the list, Disboard provides a bot that accepts a /bump command.
Normally, only one bump can happen every two hours, however, sometimes a phenomenon we call the "double bump" happens, in which two individuals both get a bump confirmation.
In practise, there are no benefits from it and it’s only a fun thing when it occurs but that begs the question how does it happen?
It’ll get very technical, but let me explain.
DISCLAIMER: This article makes some assumptions on how Disboard works behind the screens based on my own knowledge of software development.
As I’m not a developer at Disboard, I can not say 100% sure whether this is actually what happens.
Explanation
During a normal execution of the /bump, the Disboard bot received the event from the Discord gateway (either via Websockets or REST).
When this request is received by Disboard, a script starts running, most likely consisting of the following steps:
-
Receive request (
t0). -
Obtain server information from database (
SELECT). -
Check whether server is off cooldown (
CHECK).
-
Get current time (
t1) and update server information in database (UPDATE). -
UPDATEfinishing (t2). -
Report back to bot (
RETURN).
This can be visualized as such:
As one can see, there isn’t much funny business going on here.
Let’s visualize a second bump happening within two hours:
In this case, since we are still on cooldown, no UPDATE will happen, thus we will not get bumped again and Disboard will return an error message, letting us to wait a bit longer:
However, when two people try to run the /bump at the same time, a so-called "race-condition" can happen.
As you can see, the SELECT for our second bump, happens before the t2 of the first bump.
Due to this, our second bump’s information still has to work with the "old" data, we pass the CHECK and we get a double dump!
Do note that both the events are being executed independently without knowledge of the other even existing.
So which bump timer is the valid one? Well, due to the way this method works, the t1 from the second bump will be the one that ends up in the database and thus being the valid one.
Theoretical N-bumps
Some observant people may have noticed that as long as a SELECT happens before an UPDATE, a theoretical N-bump may happen, where N is only limited by how many bumps we can put between the first bump’s t0 and t2.
In the diagram below, only the fifth bump would be too late and as such, be rejected.
In theory, hundreds of bumps could be fit in, however, it’s very unlikely to happen in practise unless it’s a coordinated effort.
Additionally, it would require all of the executions to happen with a consistent timing.
In reality, however, the time between t0, t1 and t2 varies which may make it harder to pull it off.