Add client/server models & operations for "daily challenge" feature #28194
Conversation
There was a problem hiding this comment.
This being a separate class may seem gratuitous, but it is actually intentional because signalr is very inflexible towards changes of method signatures once it's already used for communication, so this is supposed to be a buffer that can allow for future extension if need be.
There was a problem hiding this comment.
Fyi SignalR also doesn't handle changes to the serialised data gratuitously. Either way any changes to this will need some sort of update.
Edit: Or maybe it does? At least in a simple test... I'm sure I've encountered this being an issue previously with the spectator frame bundles...
There was a problem hiding this comment.
I'd like to think with messagepack it should be able to handle new fields. Otherwise I'm not entirely sure why we're using messagepack (other than the size gains I guess).
There was a problem hiding this comment.
it does handle new properties, yes. we've done this before.
| [Description("Daily Challenge")] | ||
| DailyChallenge, |
There was a problem hiding this comment.
As mentioned in ppy/osu-web#11204, this is required to make daily_challenge rooms deserialise at all. Without this change deserialisation just dies, which is a bit unfortunate if/once old clients ever come in contact with these - but now it is too late to do something about it anyway.
Continuation of #28136.
Split out of the main MVP pull since this is the minimal set of changes required to implement necessary client-server communication.