Inform the client that historical messages were imported in the timeline and they should refresh the timeline in order to see the new events.
Companion `matrix-react-sdk` PR: https://github.com/matrix-org/matrix-react-sdk/pull/8354
The `marker` events are being used as state now because this way they can't be lost in a timeline gap. Regardless of when they were sent, we will still have the latest version of the state to compare against. Any time we see our latest state value change for marker events, prompt the user that the timeline needs to refresh.
> In a [sync meeting with @ara4n](https://docs.google.com/document/d/1KCEmpnGr4J-I8EeaVQ8QJZKBDu53ViI7V62y5BzfXr0/edit#bookmark=id.67nio1ka8znc), we came up with the idea to make the `marker` events as state events. When the client sees that the `m.room.marker` state changed to a different event ID, it can throw away all of the timeline and re-fetch as needed.
>
> For homeservers where the [same problem](https://github.com/matrix-org/matrix-doc/pull/2716#discussion_r782499674) can happen, we probably don't want to throw away the whole timeline but it can go up the `unsigned.replaces_state` chain of the `m.room.marker` state events to get them all.
>
> In terms of state performance, there could be thousands of `marker` events in a room but it's no different than room members joining and leaving over and over like an IRC room.
>
> *-- https://github.com/matrix-org/matrix-spec-proposals/pull/2716#discussion_r782629097*
### Why are we just setting `timlineNeedsRefresh` (and [prompting the user](https://github.com/matrix-org/matrix-react-sdk/pull/8354)) instead of automatically refreshing the timeline for the user?
If we refreshed the timeline automatically, someone could cause your Element client to constantly refresh the timeline by just sending marker events over and over. Granted, you probably want to leave a room like this 🤷. Perhaps also some sort of DOS vector since everyone will be refreshing and hitting the server at the exact same time.
In order to avoid the timeline maybe going blank during the refresh, we could re-fetch the new events first, then replace the timeline. But the points above still stand on why we shouldn't.
* Update jest monorepo
* -w
* Fix guest rooms test to use async/await instead of a done callback
The done callback was never being called because it relies on a `process.nextTick()` deep within the mock. For this test we don't get a "next tick" because the event loop is busy, so we instead cargocult some test infrastructure from surrounding tests and verify the expected API call was cleared from the queue.
* Enable github-actions reporter
* Don't override local reporters
* Stop DeviceLists at end of tests
* stop more clients
* Fix tests and DRY typing
* Fix client/crypto stopping in tests
* Fix Buffer c'tor deprecated warnings
* Fix devicelist-integ test being excluded due to poor naming
Co-authored-by: Renovate Bot <bot@renovateapp.com>
Co-authored-by: Travis Ralston <travisr@matrix.org>
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* More sonar tweaks and typing improvements
* delint
* Write some tests
* Attempt to make TS happy
* Stash tests
* Add tests
* Add `istanbul ignore if` around logging special-case for test env
* Add test
* Comments
* Parse extensible events on demand
* Decorate messages with MSC1767 when appropriate
We do this automatically to force a pool of messages in the wild we can use for testing.
* Include the SDK
* Appease linter and tests
* Change property name to appease linter
* Update SDK
- throw an AbortError when aborting is detected
- don't turn AbortError's into a ConnectionError
- also consider the string "aborted" an AbortError for unit tests
- unit tests like to reject the request with a MatrixError,
so exclude those too
Now that we're pointing at `src/` for tests, we can stop trying to load source maps from random places. With this dependency used, source maps are off by a few lines.
The earlier commit, d3ce0cb82f, has most of the juicy details on this. In addition to d3ce's changes, we also:
* Use `TestClient` in many integration tests due to subtle behaviour changes in imports when switching to ES6. Namely the behaviour where setting the request function is less reliable in the way we did it, but `TestClient` is very reliable.
* We now use the Olm loader more often to avoid having to maintain so much duplicate code. This makes the imports slightly easier to read.
