We check if we have a tracker with the UUID of the newly added appointment AND THEN actually add/update the appointment if it's not triggered. We might face a case where the first check (if tracker with UUID exists) returns false and we proceed with storing the appointment but find it already stored and panic. Something like this might happen if the user crafted two identical requests (same appointment) and timed them to be really close that they both pass the tracker non-existence check and both try to store the appointment.
Some parts of
add_appointment(the public method which users add appointments to the tower through) are not atomic:falseand we proceed with storing the appointment but find it already stored and panic. Something like this might happen if the user crafted two identical requests (same appointment) and timed them to be really close that they both pass the tracker non-existence check and both try to store the appointment.