-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add separate beatmap update flow to handle edge cases better #19378
Conversation
…e flow This can happen if the online IDs are not present in the `.osu` files. Previously this was only working due to the early logic in the import process (that relies on matching all online IDs perfectly).
@@ -670,6 +670,116 @@ public void TestImportThenDeleteThenImportOptimisedPath() | |||
}); | |||
} | |||
|
|||
[Test] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to put these in a separate file, but splitting out this test feels like it should be done as a separate pass. There's a lot of helper methods and reorganisation to be done.
Scratch that, I already managed to avoid using any dependencies while rewriting these.
I've applied changes in 8370ca9 to address the issues you've mentioned (mostly). We agree that there needs to be better separation of concerns (ie. |
Updated structure is much more readable 👍 |
Tests added, all ready to go. |
Pushing this to allow any feedback on the general flow. Will add more tests over the next day.
A few standout commits which aren't mentioned above:
2e14d87 Move implementation of updating a beatmap to
BeatmapImporter
Required to be able to write isolated tests without constructing a
BeatmapManager
orBeatmapUpdater
. But also feels like it's probably the best place to put this logic (if notBeatmapManager
, I guess).6a3e8e3 Centralise calls to reset online info of a
BeatmapInfo
Until now we were only resetting the
OnlineID
in multiple places, which leaves a beatmap in a state where it thinks it can still receive updates, even though the intention is that it shouldn't. This can be split out into its own PR if required.