Basically, the failing delayed test would fire two web requests during
the proceedings. In unfortunate timing, the first would succeed and the
test would think "everything is okay", but the actual request loading
results has not yet run.
This check ensures *something* is loaded, which seems to be enough to
make things reliable.
As seen: https://github.com/ppy/osu/pull/17252/checks?check_run_id=5545717506
The `PlaylistsResultsScreen` takes a lease on the `Beatmap` bindable
when entered. During `SetUp`, the `Beatmap` bindable is reassigned but
fails in cases where an existing test instance of the screen hasn't been
exited yet. This fix moves the assignment into the `SetUpSteps` function
after `base.SetUpSteps` is called which will exit the existing screens
first.
One of my pending work items for post-realm merge.
The lowest-level import task is no longer asynchronous, as we don't want
it to span multiple threads to allow easier interaction with realm.
Removing the `Task` spec simplifies a heap of usages.
Individual usages should decide whether they want to run the import
asynchronously, by either using an alternative override or spooling up a
thread themselves.
Was spiritually removed in https://github.com/ppy/osu/pull/16045.
This implementation is mostly taken from that PR's comment thread
verbatim, and now works due to the associated changes to
`OnlinePlayBeatmapAvailabilityTracker`.
The main goal here is to remove the inheritance, since realm doesn't
like that. Unfortunate that we can't use object initialisers in a few of
these places, but no real way around that.
The order of operation of imports means that the already-imported
instances are considered most correct (they have usually been populated
using an online source, although that is skipped in tests), so on two
consecutive test imports in a test scene, the second will lose its
online IDs completely.
This aims to ensure that all test beatmaps will have online IDs, which
is the general expected behaviour.
