Inconsistent times between get_user_recent and get_scores
nottalulah opened this issue · 4 comments
/get_user_recent and /get_scores will sometimes return differing timestamps for the same score.
This score is from /get_user_recent, and the date field is 2019-09-19 04:09:05.
This is the same score but from /get_scores, and the date field is 2019-09-19 04:09:06.
I have noticed this happen a few times, 5-6 total, once off by as much as 3 seconds.
I figure they should probably be the same.
not an authoritive answer by any means so I could be totally wrong, but ive always understood that the difference between them is that one is before the pp-processing happens, the other is after. And thus the time difference is pp-processing.
I have a project myself where I need to match the score between both of the results, and I match them on equality of all the score-related properties combined (score, maxcombo, all the hitobjects, enabled mods, etc)
If a score_id property would be available on all score-related endpoints (and if they match up between them, but im gonna assume that will be the case), that would be a better solution imo
I would have preferred score_id being available as well, but since it wasn't I used date plus user_id to determine whether I had already stored a certain score. I band-aid fixed it by allowing a few seconds discrepancy, but it's a lot slower to query and I have no way of knowing if the time difference is enough to cover all cases.
Having a score_id would solve it for sure, if that's feasible
The issue here is that both of these storages are in different tables, with no linking between. Recent scores are stores as a 24 hour cycling storage and not used for anything except heuristics.
While we could provide score_id for actual high scores, it would be a bit of a pain to clear them out when they are replaced, etc.
A huge rework is going on (as low priority) to change the score submission backend and bring it into a modern age for lazer and the future. I believe this will be fixed at that point and no earlier (because for us it is not a huge priority).
shame, but I understand. Thanks for the reply