Repository navigation
fix(chat): wait for the Matrix session restore before asking to reconnect - #421
Merged
Merged
Conversation
…nect On a fresh page load the Matrix session is restored in the background. The event page can mount chat before that restore has created the client. The chat's stored-session check treated that moment as "tokens but no working client". It showed "Connect to Matrix" for a valid session, and its cleanup reset the restore halfway through, which lets a later restore start alongside the first one. - Add waitForStartupRestore() to the Matrix client manager. It resolves once any in-flight restore settles. Concurrent startup calls now share one restore. - The chat waits on it before judging the stored session, without holding up the rest of its setup. A session that really is unusable still gets the connect prompt. - The auth store starts the restore synchronously, so the restore is visible before the store reports it is initialized. - Concurrent device ID claims in one tab now share a single claim. Web Locks are not re-entrant, so a second claim found the tab's own device lock taken and fell through to a new device, which means a full Matrix sign-in. The device ID test's private-access type no longer collapses to never, which clears that file's type errors.
…when it stalls Review of the previous commit found two problems with sharing one startup restore. Logout stays in the app, so the shared restore outlived it. If a restore was still running, the next login reused it instead of starting its own. That login could end up with no chat, or, when switching accounts, with a restore started for the previous account. The shared restore is now tied to the signed-in user, logout drops it, and a restore that was dropped or replaced can no longer clear the one that replaced it. Dropping it does not cancel it. Some restore requests have no timeout. With chat now waiting for the restore, a stuck one would leave "Loading chat room..." on screen with no way out. After 15 seconds the chat now offers a reload. Nothing is cleared, so a restore that finishes late still brings the chat up. Tests cover logout during a restore, a second user, an unmount before the restore settles, and the slow-restore message. The component tests now unmount their wrappers.
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.
Problem
Some people get "Matrix Connection Required" on an event chat even though their Matrix session is still valid. Clicking "Connect to Matrix" sends them through the Matrix sign-in again. It happens some of the time, not every time.
On a fresh page load the Matrix session is restored in the background. The event page can mount the chat before that restore has created the client. The chat's mount check saw "tokens stored, no working client" and decided the session was broken. It showed the connect prompt and ran a cleanup that reset the restore halfway through.
A second problem sits next to it. Each tab claims a Matrix device with Web Locks, which is what lets several tabs chat at once. Web Locks are not re-entrant. If two restores in the same tab claim a device at the same moment, the second finds the tab's own lock taken, gets no device, and ends up in a full sign-in.
Change
waitForStartupRestore()on the Matrix client manager resolves once any in-flight restore settles. Concurrent startup calls share one restore.Tests
waitForStartupRestore()waits for the restore, survives a failed restore, and returns at once when nothing is running.nullfor the second claim before the fix.never. Fixed, so that file has no type errors now.main(calendar, date picker, profile form, group events page). Type errors go from 305 onmainto 279, and none are in the changed files.Not tested in a real browser yet.