A participant joins a session while a question is active.
The participant sends an HTTP request to check if there is a currently active question.
The server checks the state of the session and determines that there is an active question.
Before the server can send a websocket message to the participant notifying them of the active question, the host ends the question.
This triggers a websocket notification to the participant that the active question has ended. However, since the participant doesn't know about an active question on its frontend, it ignores this message.
The server then sends a websocket notification to the participant saying there is an active question (because there was when it checked, but there isn't anymore).
Now the participant thinks there is an active question when there really isn't one.
Proposed Solution:
To address this race condition, we propose implementing a locking mechanism on the server-side to ensure that the state of the active question is consistent between the HTTP request from the participant and any changes made by the host. This can be achieved by acquiring a lock on accesses and updates to the state of the active question in relevant route handlers.
For example, in the route handler for the HTTP request from the participant to check for an active question, a lock could be acquired before checking its state and sending a websocket message to the participant if necessary. Once the websocket message has been sent (or not sent if there is no active question), the lock could be released.
This would ensure that any changes to the state of the active question made by the host (such as ending an active question) would only occur after the participant has received a response to their HTTP request. In other words, while a lock is held on accesses and updates to the state of the active question, any attempts by the host to end an active question would be blocked until after the lock is released.
there's an extremely small time window in which this race condition could occur, and as such is highly improbable. Therefore, it's not a priority. but technically it could happen
Problem:
Proposed Solution: To address this race condition, we propose implementing a locking mechanism on the server-side to ensure that the state of the active question is consistent between the HTTP request from the participant and any changes made by the host. This can be achieved by acquiring a lock on accesses and updates to the state of the active question in relevant route handlers.
For example, in the route handler for the HTTP request from the participant to check for an active question, a lock could be acquired before checking its state and sending a websocket message to the participant if necessary. Once the websocket message has been sent (or not sent if there is no active question), the lock could be released.
This would ensure that any changes to the state of the active question made by the host (such as ending an active question) would only occur after the participant has received a response to their HTTP request. In other words, while a lock is held on accesses and updates to the state of the active question, any attempts by the host to end an active question would be blocked until after the lock is released.