Conversation
Add a workaround for the fact that MatrixChat attempts to use React state for the state of a state machine: a small `sleep` to let the state settle. As a result, it turns out we may not see the "Syncing..." state, and in general `waitForSyncAndLoad` doesn't seem to be doing anything useful.
| // we are logged in, but are still waiting for the /sync to complete | ||
| await screen.findByText("Syncing…"); | ||
| // initial sync | ||
| await act(() => client.emit(ClientEvent.Sync, SyncState.Prepared, null)); |
There was a problem hiding this comment.
this "client.emit" already happens in the startClient mock above, so I think (now that it happens after an appropriate delay), this is redundant.
Further, the fact that the ClientEvent.Sync does happen after a delay (and does what it should) means that the test never gets the chance to see the "Syncing..." check, so that had to go.
Generally, all these flushPromises look like a fudge, and we're much better off just doing an await screen.findBy... to look for the thing we actually want.
| // wait for logged in view to load | ||
| await screen.findByLabelText("User menu"); |
There was a problem hiding this comment.
this replaces the findByLabelText that used to be in the withoutSecuritySetup branch of waitForSyncAndLoad
| expect(screen.getByRole("heading", { name: "Welcome Ernie" })).toBeInTheDocument(); | ||
| }); | ||
|
|
||
| describe("when server supports cross signing and user does not have cross signing setup", () => { |
There was a problem hiding this comment.
(servers always support cross-signing nowadays)
2 participants
Add a workaround for the fact that MatrixChat attempts to use React state for the state of a state machine: a small
sleepto let the state settle.As a result, it turns out we may not see the "Syncing..." state, and in general
waitForSyncAndLoaddoesn't seem to be doing anything useful.I think this fixes #30690.