* Fix test message utils using overload
* Tweak existing tests
* Add test around `MatrixClient::getEventTimeline`
* Fix test to actually exercise the faulty behaviour
* Extract timelineSet thread belongs logic and test it
* tweak method name
* 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>
* Update relations after every decryption attempt
If an event is encrypted the aggregation cannot pick up the relation types.
Before this change there was exactly one aggregation retry after decryption.
If the events are being decrypted afterwards (for example on restore
from key backup) the aggregation was not aware of that.
This change adds relation updates after every decryption event if there
has been a decryption error.
Signed-off-by: Michael Weimann <michaelw@matrix.org>
* 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
* Add PTT call mode & mute by default in PTT calls (#2311)
No other parts of PTT calls implemented yet
* Make the tests pass again (#2316)
3280394bf9
made call use a bunch of methods that weren't mocked in the tests.
* Add maximum trasmit time for PTT (#2312)
on sender side by muting mic after the max transmit time has elapsed.
* Don't allow user to unmute if another user is speaking (#2313)
* Add maximum trasmit time for PTT
on sender side by muting mic after the max transmit time has elapsed.
* Don't allow user to unmute if another user is speaking
Based on https://github.com/matrix-org/matrix-js-sdk/pull/2312
For https://github.com/vector-im/element-call/issues/298
* Fix createGroupCall arguments (#2325)
Comma instead of a colon...
