Why is this a thing at all? How has it survived this long? I don't know.
As far as I can tell this only manifests on selected beatmaps with "slow
swells" that spend the entire beatmap moving in the background. On other
beatmaps the tick is faded out, probably due to the initial transform
application that normally "works" but fails hard on these slow swells.
Can be seen on https://osu.ppy.sh/beatmapsets/1432454#taiko/2948222.
It's no longer possible to just assume that using the ambient
`WorkingBeatmap` is gonna work.
Bit dodgy but seems to work and also I'd hope that `WorkingBeatmapCache`
makes this not overly taxing. If there are concerns this can probably be
an async load or something.
Closes https://github.com/ppy/osu/issues/28791.
The reason why nudging was not changing hyperdash state in catch was
that `EditorBeatmap.Update()` was not being called on the objects that
were being modified, therefore postprocessing was not performed,
therefore hyperdash state was not being recomputed.
Looking at the usage sites of `EditorBeatmap.PerformOnSelection()`,
about two-thirds of callers called `Update()` themselves on the objects
they mutated, and the rest didn't. I'd say that's the failure of the
abstraction and it should be `PerformOnSelection()`'s responsibility to
call `Update()` there. Yes in some of the cases here this will cause
extraneous calls that weren't done before, but the method is already
heavily disclaimed as 'expensive', so I'd say usability should come
first.
Flushes are assumed to have already come from a definitive state change
(read: disconnection). Allowing the exceptions that come from failing
the flushed requests to trigger the `Failing` code paths makes
completely incorrect behaviour possible.
Because it'll fail anyway - there is either no username or no password.
The reason why this is important is that the block was also setting API
state to `Connecting`.
When API is in `RequiresSecondFactorAuth` state, `attemptConnect()` is
called over and over in a loop, with no sleeping, which means that the
scheduler accumulates hundreds of thousands of these delegates. Sure you
could add a sleep in there maybe, but it seems pretty wasteful to have
the `localUser.IsDefault` guard *inside* the schedule anyway, so this is
what I opted for.
