Fell out when attempting
https://github.com/ppy/osu-server-spectator/pull/346.
Functionally, if a true non-`HubException` is produced via an invocation
of a spectator server hub method, this doesn't really do much - the
error will still log as 'unobserved' due to the default handler, it will
still show up on sentry, etc. The only difference is that it'll get
handled via the continuation installed in `FireAndForget()` rather than
the `TaskScheduler.UnobservedTaskException` event.
The only real case where this is relevant is when the server throws
`HubException`s, which will now instead bubble up to a more
human-readable form. Which is relevant to the aforementioned PR because
that one makes any hub method potentially throw a `HubException` if the
client version is too old.
Obviously this does nothing for the existing old clients.
Mostly trying to give more space to the queue as we add more vertical
elements to the middle area of multiplayer / playerlists. This whole UI
will likely change – this is just a stop-gap fix.
In some scenarios, multiplayer spectator would not tick over to the next
beatmap.
Here's an example:
- Room has two items queued
- Local user starts download of both
- First beatmap starts and download is complete
- First beatmap ends (spectating is active)
- Second beatmap starts but download is not complete
In this scenario, the local client will get stuck at the spectator
screen due to the `onLoadRequested`-invoked screen change being early
exited.
It would require manual recovery (clicking back button) to return to a
sane state.
If `IAPIProvider.State` changes from `Online` at any point when being on
an `OnlinePlayScreen`, it will be forcefully exited from. However,
`MultiplayerMatchSubScreen` had local logic that suppressed the exit in
order to show a confirmation dialog.
The problem is, that in the suppression logic,
`MultiplayerMatchSubScreen` was checking
`MultiplayerClient.IsConnected`, which is a SignalR flag, and was not
checking `IAPIAccess.State`, which is maintained separately. Due to
differing timeouts and failure thresholds, it is not impossible to have
`MultiplayerClient.IsConnected == true` but `IAPIAccess.State !=
APIState.Online`.
In such a case, the match subscreen would wrongly consider itself to be
still online and due to that, push useless confirmation dialogs, while
being in the process of being forcefully exited. This then caused the
dialog to cause a crash, as it was calling `.Exit()` on the screen which
would already have been exited by that point, by the force-exit flow.