This handles the case where on initial API connection, the server
responds with an `Unauthorized` response. It doesn't perform this same
checking/handling on every API request, which is probably what we want
eventually.
Opting to not address the full issue because I know this is going to be
a long one (see
05c50c0f6c/osu.Game/Online/API/APIAccess.cs (L233)).
Specifically, `Cancel()` calls were not thread safe. Due to a series of
events, `ListPollingComponent` could call `Cancel` from a non-update
thread, leading to a race condition where both a `Success` and `Fail`
event can be fired.
This is intended to be the simplest fix possible, locking and guarding
specifically on the callbacks. Further work could be done in the future
to improve the flow surrounding `pendingFailure`, potentially reducing
redundant work and cleaning up the code, but that's not happening here.
Closes https://github.com/ppy/osu/issues/13632.
A null there indicates a deserialisation error and therefore due to the
catch block immediately succeeding the changed line everything will
continue to work as intended.
As reported in #12718, it turns out that temporary files from beatmap
set downloads performed via the beatmap listing overlay could remain in
the user's filesystem even after the download has concluded.
The reason for the issue is a failure in component integration.
In the case of online downloads, files are first downloaded to a
temporary directory (`C:/Temp` or `/tmp`), with a randomly generated
filename, which ends in an extension of `.tmp`.
On the other side, `ArchiveModelManager`s have a `ShouldDeleteArchive()`
method, which determines whether a file should be deleted after
importing. At the time of writing, in the case of beatmap imports the
file is only automatically cleaned up if the extension of the file is
equal to `.osz`, which was not the case for temporary files.
As it turns out, `APIDownloadRequest` has a facility for adjusting the
file's extension, via the protected `FileExtension` property. Therefore,
use it in the case of `DownloadBeatmapSetRequest` to specify `.osz`,
which then will make sure that the `ShouldDeleteArchive()` check in
`BeatmapManager` picks it up for clean-up.
Until now, API requests sent to dummy API were just lost in the void. In most cases this somehow worked as expected, but any logic which is waiting on a request to finish will potentially never get a response.
Going forward, I'm not 100% sure that every `Wait` on a web response will have local timeout logic (I think there is a certain amount of assumption that this is being managed for us by `APIAccess`), so I've made this change to better handle such cases going forward. Now, rather than nothing happening, requests will trigger a failure via the existing exception logic rather than silently pretending the request never arrived.
