Refetch leaderboard when (slow) retrying a beatmap #34662
Conversation
Probably closes ppy#34645. Obviously this is only good if the score has managed to process online and slot into a leaderboard before the user requested a retry. I can't make miracles happen. Notably this is not applied to quick retry, because it would make quick retry slower, and the presumption is that if the user is quick-retrying their last score is likely useless for global leaderboards anyway. (The one exception to that last part is possibly quick-retrying from results screen, which is a flow that we have, but maybe fine to ignore it...?)
bdach
added
area:gameplay
quick fix
|
I use the quick retry from the result screen quite a lot personally ^^. Edit: I think that having the quick retry be a bit slower when at the result screen isn't that bad, since you already waited for that screen to appear. |
| // that said, only do this when the user is *not* quick-retrying. | ||
| // this avoids the quick retry becoming longer than it needs to (because an extra API request has to complete before gameplay can start), | ||
| // and if the user is quick-retrying, their last score is most likely not important for global leaderboards, or the user won't care. | ||
| refetchLeaderboard(force: !quickRestartRequested); |
There was a problem hiding this comment.
Is the extra time added due to the request getting queued in the single API queue? I'm wondering if we should be firing out-of-ban to avoid this 🤔
There was a problem hiding this comment.
That is the reasoning yes.
Firing out-of-band is probably going to be ugly code because you're going to need to tell the game-global component to do that conditionally.
There was a problem hiding this comment.
Yeah, it's a bit like that. Hopefully we can improve in the future.
Let's go with this for now since it's a step in the right direction.
3 participants
Probably closes #34645.
Obviously this is only good if the score has managed to process online and slot into a leaderboard before the user requested a retry. I can't make miracles happen.
Notably this is not applied to quick retry, because it would make quick retry slower, and the presumption is that if the user is quick-retrying their last score is likely useless for global leaderboards anyway. (The one exception to that last part is possibly quick-retrying from results screen, which is a flow that we have, but maybe fine to ignore it...?)