Conversation
Floha258
requested changes
Feb 4, 2026
Collaborator
Floha258
left a comment
There was a problem hiding this comment.
Got some minor suggestions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a local timer option to rooms, which is always active, regardless of if a game is opted in to the racetime.gg beta. This additionally further fleshes out the RaceHandler interface, and in turn adds additional functionality to the racetime interface as well.
New Features
Changes
Bug Fixes
Technical Notes
The code in this PR is still a bit messy. Over time, the room class has become a bit of a catchall and has largely become overgrown and bloated. The original racetime integration was designed specifically for racetime, with no regard for potentially adding other systems. A basic interface was extracted on top of it as a a first step in refactoring, but that was only a half measure, and didn't make many of the needed changes to the room class itself (in fact the object in the room itself was still typed as a RacetimeHandler). This PR gets, probably 75% of the way to having RaceHandlers be completely interchangeable, however, there is still a large dependence on some racetime specific design elements that needs to be refactored. I think this PR has already scope creeped enough, and that refactor should stand on its own, since it also begs some non-trivial questions about when information clients need about races and how that should be structured.
This also slightly refactors how RaceHandler works with the player data structure, leveraging the full structure instead of some arbitrary identifier within the the player that the player must pass in. This ultimately decouples the player structure from services such as the racetime auth token service, moving that responsibility into the implementation of the relevant race handler.
Another major divergence in this PR is that all race related actions included in this PR occur over websocket and only websocket. Previously, racetime actions had to be performed over http due to websocket authentication limitations, which have since been overcome. However, no work has been done to bring the
/actionsframework in line with the websocket implementation. This isn't particularly an issue, but something worth noting. I think ultimately this leads to an interesting refactor opportunity with rooms - if we can make the websocket message into a generic message type that we validate (such as with zod) based on the action, we can share core handling logic between websocket and http., but that is way beyond the scope of discussion for this PR.