Description
Describe the bug
The list of registrations as it appears on /edit/registrations is not ordered in the same way as I would expect from the registrantId (saved to WCIF).
To Reproduce
Take for example: Mainzelcubing2025 and look at the very last two people that I accepted, this is https://www.worldcubeassociation.org/competitions/registrations_v2/Mainzelcubing2025/28722/edit and https://www.worldcubeassociation.org/competitions/registrations_v2/Mainzelcubing2025/409431/edit in that order, based on their order on that registration edit page which is correct only up to second precision.
However, when I look at the private WCIF, I see that the registrations for those two are swapped compared to that (registrantId 51 and 50, not 50 and 51).
I can only guess that this has to do with registration model does not take milliseconds into account, while the WCIF & registration history do take milliseconds into account. Because indeed when I compare them from the reg history (I need to interrupt the page with web developer tools and inspect the variables), the WCIF registrantId matches my expectation from the "Worker processed" actions.
Here is what I describe, but with the actual numbers:
position on reg edit page | first timestamp in reg. history (Worker processed) | WCIF registrantId
50 | "2025-02-10T18:00:13.350Z" | 51
51 | "2025-02-10T18:00:13.161Z" | 50
So you see, the history matches with the registrantId, but it does not match with the order on the /edit/registrations page and the export that is derived from that. It appears that with only second precision on /edit page, you get a random millisecond order, because all of them are capped to .000
Expected behavior
Same order for /edit/registrations and registriantId.
Bonus: Can you advise, which order should we refer to in the future? Reg history order or reg edit order? Or, can you add the cut off milliseconds from this history also to the regular registered_on timesamp?
To make things easier, can you add the first event that is stored in the registration history (Worker processed => with the timestamp including milliseconds) as an entry in the WCIF json? It would be great to have one place that contains that info to automatically process.
Screenshots
Desktop (please complete the following information):
- OS: MacOS
- Browser: Chrome
- Version: 128.0.6613.120 (Official Build) (arm64)
Smartphone (please complete the following information):
Additional context
At least in regions that do external payment (👋) we have to rely on such order to find when the registration was completed.
The workaround „works“ but is very inconvenient, not automated and until we have figured it out manually, there will already be people emailing us why XYZ is not on the registration list yet.
Just for completeness, the csv export or any user-facing things with custom ISO schemes are not the issue, the milliseconds are not available in the first place for registered_on (only for history -> timestamp).
Activity