* utils: Fix bug in deepCompare which would incorrectly return objects with disjoint keys as equal
* Fix bugs in sync test
This test wrongly asserted that `initialSyncLimit` would be used to make a filter
It is used only for the initial sync inline filter, and not in POST /filter
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Small tidy-up to sync.ts
* Convert doSync into a while loop
* Apply `initialSyncLimit` only to initial syncs
* Convert matrix-client-syncing spec to TS
* Add tests around initial sync filtering
* Switch confusing filterId field for `filter`
* Tweak doSync error control flow
* Fix error control flow intricacies
* use includes
* Add tests
* Fix some strict mode errors
* Fix more strict mode errors
* Fix some strict mode errors
* Re-emit room state events on rooms
This also fixes some potential memory leaks and abuse of
removeAllListeners in sync.ts.
* Remove some stray whitespace
* Deduplicate some code to appease SonarCloud
* Name helper function more explicitly
* Refactor Relations to not be per-EventTimelineSet
* Fix comment and relations-container init
* Revert timing tweaks
* Fix relations order test
* Add test and simplify thread relations handling
* Fix order of initialising a room object
* Fix test
* Re-add thread handling for relations of unloaded threads
* Ditch confusing experimental getter `MatrixEvent::isThreadRelation`
* Fix room handling in RelationsContainer
* Iterate PR
* Tweak method naming to closer match spec
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>
This API is due for removal in Synapse and has been deprecated for a very long time. People should move away from it soon, but just in case we'll declare this as a breaking change.
There is no impact on sync storage here: we happen to store the data in a way that is backwards-compatible for group-supporting clients, and the code guards against missing data from the stores. So, if someone were to revert, they'd be "safe" (probably lose all their group info, but the app wouldn't crash).
Adds an unstable hint for clients to know whether to render an event in the room timeline or in a thread
There are currently no MSC associated with that unstable "io.element.in_thread" property as I am only experimenting before settling on a specific approach
Michael Telatynski