When a `SubmittingPlayer` gameplay session ends with the successful
completion of a beatmap, `PrepareScoreForResultsAsync()` ensures that
the score submission request is sent to and responded to by osu-web
before calling `ISpectatorClient.EndPlaying()`.
While previously this was mostly an implementation detail, this becomes
important when considering that more and more server-side flows (replay
upload, notifying about score processing completion) hook into
`EndPlaying()`, and assume that by the point that message arrives at
osu-spectator-server, the score has already been submitted and has been
assigned a score ID that corresponds to the score submission token.
As it turns out, in the early-exit path (when the user exits the play
midway through, retries, or just fails), the same ordering guarantees
were not provided. The score's submission ran concurrently to the
spectator client `EndPlaying()` call, therefore creating a network
race. osu-server-spectator components that implciitly relied on the
ordering provided by the happy path, could therefore fail to unmap the
score submission token to a score ID.
Note that as written, the osu-server-spectator replay upload flow is
not really affected by this, as it self-corrects by essentially polling
the database and trying to unmap the score submission token to a score
ID for up to 30 seconds. However, this change would have the benefit of
reducing the polls required in such cases to just one DB retrieval.
Another casualty of edc78205d5. This
particular button was actually *relying* on receiving positional events
from its entire bounding box rather than `Content`, in order for the
button to be htitable more easily, which broke as other buttons were
fixed to behave more in line with expectations.
Upon closer inspection this is another case of a weird carried-over
construction. The button doesn't really need to inherit `OsuButton` or
do any of the arcane stuff that it was doing, so it's now a plain
`OsuClickableContainer` with less `Content` hackery.
Having both was a bit too much. Still not happy with this but it's a bit
less sensory overload.
I think while it's cool being able to show nested screens like this, it
needs more thought to actually be a good experience.
As it turns out, in current `master`, if a gameplay session ends
normally (i.e. by the player completing the beatmap in full), then
the spectator server `EndPlaying()` method will not be called until
`SubmittingPlayer.OnExiting()`, which in practice turns out to be
the moment where the user exits from the post-gameplay results screen
back to song select.
There is seemingly no reasonable cause for not calling this earlier. In
fact the solo spectator flow looks more broken without this call than
with, because without it the spectator view just hangs until the
spectated player exits gameplay, and *only then* shows results, rather
than do it upon normal gameplay completion.
