As spotted in https://github.com/ppy/osu/pull/33191/checks?check_run_id=42460062656
Seems like just a bog-standard race. Could be reproduced via
diff --git a/osu.Game/Screens/Ranking/SoloResultsScreen.cs b/osu.Game/Screens/Ranking/SoloResultsScreen.cs
index d11e7db178..1a594fd21b 100644
--- a/osu.Game/Screens/Ranking/SoloResultsScreen.cs
+++ b/osu.Game/Screens/Ranking/SoloResultsScreen.cs
@@ -45,6 +45,8 @@ protected override async Task<ScoreInfo[]> FetchScores()
if (Score.BeatmapInfo!.OnlineID <= 0 || Score.BeatmapInfo.Status <= BeatmapOnlineStatus.Pending)
return [];
+ await Task.Delay(5000).ConfigureAwait(false);
+
var criteria = new LeaderboardCriteria(
Score.BeatmapInfo!,
Score.Ruleset,
Closes https://github.com/ppy/osu/issues/27589.
Follows osu! spinner precedent in storing the holding state to the
judgement result rather than attempting to keep it in the DHO (which is
prone to getting dropped on pool re-use).
Closes https://github.com/ppy/osu/issues/22086
While this *is* a case of aspire-tier breakage, I hesitate to dismiss it
as wontfix, because the fix is somewhat easy, and probably results in
better accuracy across the board.
The issue in question here manifests when there is a significant amount
of lead-in time, like what the beatmap linked in the aforementioned
issue (https://osu.ppy.sh/beatmapsets/948643#osu/1981090) does.
Both stable and lazer record replay frames using absolute timestamps,
*but* the legacy replay format after the first frame uses time *deltas*,
i.e. amounts of time elapsed since the previous frame. This means that
the decoding process of the replay has to reconstruct absolute timestamps
by doing cumulative summation starting from the first frame.
When the very first frame has a timestamp that is very large in
magnitude (say, like the negative 2 billion that the beatmap in question
uses), this will lead to error if the cumulative summation is using
floating point numbers, because it will be adding a small magnitude
frame delta to a large magnitude cumulative absolute time. Which means
that sometimes adding the frame delta to the cumulative time *will not
change the cumulative time*, leading to the loss of time and thus replay
de-synchronisation.
Knowing that the legacy replay format only deals in integral time
values, however, this can be circumvented by just using a large enough
integral number type for the cumulative time tracking instead. I think
`long` in this case can be safely used "large enough" for our purposes:
> Console.WriteLine(long.MaxValue);
9223372036854775807
9 223 372 036 854 775 807 ms equals 292 277 024,6269277149 years