Handle Battle, Lobby, Party, and Matchmaking status reconnections - #711
Merged
Conversation
Made a shared springString utility Cleaned up launch triggers slightly Added a launch for user/self currentBattle
Prompts user to rejoin a current battle if user/self indicated that one was active. Battle connection details are now preserved so the user can choose to rejoin immediately or later. We will need some kind of "rejoin active battle" option in the UI to do that, but this sets it up for that.
NavBar main logo will now show a "in battle" animation over the logo to attract attention to itself. Clicking on the element will display the Rejoin Battle Modal. Animation will only show if there is a known battle to join.
This was
linked to
issues
Aug 24, 2026
CI will fail because of errors in the server-provided objects
Dev server has been fixed
A different PR (campaign data) had this fixed but was never applied, and got forgotten about. Revived to fix the issue.
We have to always send the party status because prechecking for a null value means we have zero parties and we still need to tell the client (maybe they were kicked while disconnected, etc.).
Now properly handling situations where the value becomes null/undefined because the client was removed from the party/lobby/battle while disconnected.
burnhamrobertp
left a comment
burnhamrobertp
left a comment
Contributor
There was a problem hiding this comment.
Read this against a local teiserver with the matchmaking reconnect cases driven end to end, so a few of the comments below reference what the server actually sends. Nothing here is about the parts you already flagged under Server Issues.
4 tasks
Contributor
Author
|
Note to self; implement |
Using idempotent lobby/join to refresh chat had a client side-effect of purging chat history as it assumed it was a newly joined lobby and not potentially a pre-existing one.
Replaces all uses of window.tachyon.request() with requestStructured().,
burnhamrobertp
suggested changes
Aug 31, 2026
Party and Lobby now use a Map like Users did. This means that we no longer have to worry about chat clearing/preserving when we get lobby or party events in 'user/self'
This request needed two parameters. To avoid ambiguity, each has been tied to named properties of a single object with neither optional. All existing references updated.
ip:string > ips:string[] Added battleId where appropriate.
Contributor
Author
|
Tests for state changes mid-disconnection:
|
Server needs updated
Both the event handler (main) and rejoin action (renderer) needed to handle the missing property
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
2 participants
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.
Fixes #665 #666 #667 #668 and #707 and closes parent #664
Each store has a listener for
user/selfevent and handles it's own data as appropriate.A modal now prompts the user to rejoin their battle if the server indicates they were in one.
If the modal is dismissed, the BAR logo is overlaid with an attention-grabbing animated crossed swords. Clicking it will re-prompt them to rejoin the battle via the modal again. Various events and actions will forcibly clear the "in battle" state as appropriate.
Server Issues
At this time, it is not possible to reliably know that a battle ended and the autohost has shut down because
battle/endedis not being sent.Matchmaking queue status upon reconnection is always
no_matchmaking, which can be incorrect. Any newly received matchmaking status events afterward from the server will update it correctly, however.See below:
battle/endedevent teiserver#1497user/selfevent teiserver#1450To alleviate the missing implementations, tests are included to cover the expected behavior when they are added. Live validation will happen separately once possible. Since this only impacts multiplayer functions, which are locked behind Dev Mode, this is considered an acceptable compromise to holding the PR back.
AI / LLM usage statement:
GH Copilot was used for some tests and code generation under my direction, and for evaluating options for different approaches.