# 2025 Issues — Summary 1. Decouple exam opening from training contest status 2. Handle simultaneous contest starts to prevent server overload 3. Fix invalid answer submission fallback 4. Improve Start button visibility on mobile 5. Clean up failed and duplicate participations 6. Prevent multiple participations per student 7. Make recovery codes more robust and forgiving 8. Investigate unnecessary recovery code submissions 9. Fix finalAnswerTime and data persistence on page reload 10. Investigate rapid duplicate participations from different machines 11. Add QR code upload and deadline system 12. Add a long code upload page 13. Store QR codes in the system for reference 14. Verify score handling for edge cases --- ## 1) Decouple exam opening from training contest status **Cause:** The system was using training contest status in addition to the exam to allow kids to enter, which caused the opening to be delayed by 2 minutes. **Actions during contest:** France-ioi re-opened the training contest. **Long term solution:** Change the code so that opening the exam is enough to let students in, removing the dependency on the training contest status. ## 2) Handle simultaneous contest starts to prevent server overload Many kids started the contest at exactly the same time, causing memory to be exceeded on all servers. Kids couldn't start the contest until the issue was resolved about 5 minutes later. The root causes were: kids were not warned to spread out their start times over a range; 20 servers are not enough when all kids start simultaneously; and AWS monitoring doesn't show memory status, so France-ioi didn't see it coming. **Actions during contest:** France-ioi added more servers and killed older ones to be safe, resolving the issue within 5 minutes. KSA told kids to try again later. **Long term solutions:** - KSA: warn kids ahead of time to spread out when they start. - France-ioi: use more than 20 servers, and/or servers with more memory. - France-ioi: trigger more servers earlier in terms of CPU usage. - France-ioi: investigate ways to monitor memory usage — custom metrics, or using the castorguard tool to limit queries when memory is full. - Figure out a way to delay start of the participation for some contests. ## 3) Fix invalid answer submission fallback This was caused by the server overload (issue 2) and one of the alternate ways we attempted to send answers, which was invalid and triggered the error message. Some kids received the message and got worried; 2 took the time to send an email. **Actions during contest:** KSA told kids to try continuing a couple of times, cancel and ignore if it persists, but to be careful at the end if there is a file to send or a QR code. **Long term solution:** France-ioi will fix the configuration issue. ## 4) Improve Start button visibility on mobile At least one kid couldn't see the Start button and instead clicked "open" on their past training. The system told them it was closed but then sent them to the main page of the contest, leaving their personal page. On mobile, it's easy to miss the button, and the feedback when trying to re-open a participation on a closed training is not very clear. **Long term solutions:** France-ioi will make the screen more mobile-friendly and improve the feedback UI when a student tries to re-open a participation on a closed training. ## 5) Clean up failed and duplicate participations It looked like 600+ kids entered their code and clicked the button but didn't end up starting. After investigations, all but 14 of them are kids who, due to the initial overload, created two participations — one of which was never started. See issue 6 for the long term solution. ## 6) Prevent multiple participations per student 76 kids were able to participate twice. Due to the server overload, they created multiple participations that never started. After they finished the participation that worked, they could see the other participations and re-open them. **Actions for these kids:** France-ioi exported data about these participations to provide KSA with all the data. KSA will compare participation dates and decide which one to keep, taking the best one. **Long term solutions:** France-ioi will consider deleting failed participations automatically when creating a new one, or fix what makes it possible to start a second participation. This needs to be discussed internally. ## 7) Make recovery codes more robust and forgiving Some kids sent invalid recovery files that we had to handle by hand. We encountered the following situations that we were able to resolve: the code was mostly OK but missing one or two `=` signs at the end; the code was in a PDF so we copied the content and removed `\r\n`; the code was incomplete, often cut at the first `2K\`, but we could figure out the password and verify that we received the answers; the code had extra characters at the end which we removed; they sent an image with only part of the code but we could identify who it was and verify the answers were received; or the code was missing the very beginning but we could figure out the missing part and recover the data. **Situation where we're not 100% sure it's resolved, but probably:** Some codes contained strange `2K/` strings that we replaced with `2Kf`. This is likely correct as it appears to be the encoding of an error message that doesn't impact grading. **Situations we can't resolve:** The code is incomplete — we can figure out the password but didn't receive all answers (though there may be a QR code); or the code is incomplete and missing the beginning, so we can't identify who it is. ## 8) Investigate unnecessary recovery code submissions A lot of the time, we already received the data but kids still ended up sending us their file. **TODO:** Check why this happens and make it so that we can tell them it's not needed. The leading theory is that the data was sent but the acknowledgement was not received by the browser. ## 9) Fix finalAnswerTime and data persistence on page reload If students tried to re-open their participation before we closed the contest, it set the finalAnswerTime date. But that date is supposed to indicate whether we received all the data or not. Additionally, students end up getting a QR code, but that QR code doesn't contain the points from the unsent data. This may explain issue 8). **Ideas:** Store data in local storage so that it is not lost if they simply reload the page. Also, log information about what happened (last page reload, connection issues, etc.). ## 10) Investigate rapid duplicate participations from different machines A few students participated twice within seconds and actually scored points in both, sometimes from two different machines. This was probably only possible due to the server overload that enabled multiple participations, but it's still surprising. We need to ask the students what happened. ## 11) Add QR code upload and deadline system We need a way to know when scores are final. For that, we need a clear deadline by which students can scan their QR code and have it taken into account if it contains a score different from the one we received during the contest. We also need a way, before this deadline, for students to check the score we currently have, so they know whether they really need to scan the QR code. A request from students to scan the QR code after the exam should not be sent, and this should be mentioned in the instructions. If a long code appears, it should be sent even if the student did not face any problems. The long code should be uploaded from the system within 24 hours (email is not an efficient tool for this process). 30 students claimed to have a score that was different but sent it too late. --- ## 12) Add a long code upload page Add a page for students to upload their long code electronically, so it can be accessed and read by the system instead of being sent via email. The page should automatically detect if there is an issue with the long code. ## 13) Store QR codes in the system for reference Add an option to save the QR code in the system, so it can be used as a reference in case there is no grade, without requiring a student request. Students will also be asked to keep a copy with them. ## 14) Verify score handling for edge cases Two edge cases need to be verified: - What happens if the contest ends just as students were finishing their last questions — could that score be missed? - What happens if an answer is sent with a delay — is it still accepted?