Probably closes https://github.com/ppy/osu/issues/35650.
Realm slow, episode 23894. I can't reproduce freezes as big as the video
in the issue is showing but 'realm slow' is 99% the culprit, because
affected user's database is not small.
Because I just wasted 30 minutes trying to debug why a skin provided by
a user in an issue thread was failing to deserialise, only to realise
halfway through that the deserialisation error I was seeing was *from
the fallback path and thus a complete red herring*.
Closes https://github.com/ppy/osu/issues/35651.
The reproduction steps provided in the issue are too complex even. In my
testing all you need to do is go into editor, replace the background via
external editing, and exit out to song select; you'll immediately see
loss of selection on the carousel, the set panel still using the old
background, and eventually a crash when you attempt to re-select any of
the difficulties of the edited set.
`HandleItemsChanged()` - an optimisation aiming to reduce the number
of redundant re-filters due to minor changes to realm models that aren't
visible to the user anyway - ignoring changes to `BeatmapInfo.ID` after
re-entering song select post-external edit meant that song select would
retain stale beatmap models that no longer existed in the realm
database, thus failing refetch attempts via `GetWorkingBeatmap()` or
https://github.com/ppy/osu/blob/8f6f859c15bdfc9f10d5754c254fca7b9dd9bc9b/osu.Game/Screens/SelectV2/FooterButtonOptions.cs#L56-L57
RFC. Written to address
https://osu.ppy.sh/community/forums/topics/2150023.
Few other things we might want to happen here:
- pause the track when starting the drag
- figure out what to do when a drag is held while the track changes in
the background (which was impossible to happen before this)
but I want to see the reaction to this first.
* Add failing test coverage for blocking users not removing their messages from public channels
* Fix messages from blocked users being visible in public channels
Closes https://github.com/ppy/osu/issues/35633.
It appears that the expectation from web here is that messages from
blocked users should be excised client-side. Compare:
https://github.com/ppy/osu-web/blob/12dd504255bddc0cb37701c392c460222b6825db/resources/js/chat/conversation-view.tsx#L104
This implementation won't *restore* the messages after a block and
unblock, but I kind of... don't care if I'm honest with you? Making that
happen will result in a bunch of complications for no reason, so I'm
fine waiting for anyone to complain about it.
RFC, lowest effort solution for https://github.com/ppy/osu/issues/34979.
The `SkinImporter` conditional *is* hella ugly, but anything less ugly
will require taking a hammer to structures. Maybe passing version via
the import flow, maybe even trying to make the `EnsureMutableSkin()`
flow somehow attempt to read the `skin.ini` that's in resources. No
idea.
Properties from `skin.ini` that were defaults or that lazer can't
(won't ever?) understand snipped.
`VerificationFailureResponse.RequiredSessionVerificationMethod` not
being nullable means that if it was missing in the verification
response, it would not be `null` but default to `TimedOneTimePassword`
instead, therefore showing TOTP-related error messages to users that
never enabled it rather than the user-facing message they were supposed
to.
Most easily tested on a local full-stack environment with
```diff
diff --git a/app/Libraries/SessionVerification/MailState.php b/app/Libraries/SessionVerification/MailState.php
index 305a2794ec0..3c2d15f335b 100644
--- a/app/Libraries/SessionVerification/MailState.php
+++ b/app/Libraries/SessionVerification/MailState.php
@@ -14,7 +14,7 @@ use Carbon\CarbonImmutable;
class MailState
{
- private const KEY_VALID_DURATION = 600;
+ private const KEY_VALID_DURATION = 10;
public readonly CarbonImmutable $expiresAt;
public readonly string $key;
```
applied so that you don't have to wait 10 minutes to trigger the
failure.
Issue was bisected to [this commit](https://github.com/ppy/osu/pull/29616/commits/6f1664f0a60fc08995d737e40272b61742fbe580)
This change in the commit outlined is what caused the issue:
```diff
BreakOverlay = new BreakOverlay(working.Beatmap.BeatmapInfo.LetterboxInBreaks, ScoreProcessor)
{
Clock = DrawableRuleset.FrameStableClock,
ProcessCustomClock = false,
- Breaks = working.Beatmap.Breaks
+ BreakTracker = breakTracker,
},
```
`BreakTracker` always initializes breaks as `new Period(b.StartTime, b.EndTime - BreakOverlay.BREAK_FADE_DURATION);` leaving room at the end to account for the fade before resuming gameplay.
Because of this, changing the `BreakOverlay` to use a `BreakTracker` instead of the original beatmap breaks caused each break to be `BREAK_FADE_DURATION` shorter than it was originally - which in this case is 325ms - leading to the discrepancy between the background fadeout and the overlay fadeout.
Since the current behavior is 'correct', aligning the overlay with the rest of the beatmap such as background fadeout, I changed the timing to account for the shorter duration instead of revert the overlay initialization.
* Add new API property backing for tiered rank
* Slightly refactor `ProfileValueDisplay` for direct access to things that will need direct access
* Extract separate component for global rank display
* Add tiered colours for global rank