* Do not assume that a relation lives in main timeline if we do not know its parent
* For pagination, partition relations with unknown parents into a separate bucket
And only add them to relation map, no timelines
* Make addLiveEvents async and have it fetch parent events of unknown relations to not insert into the wrong timeline
* Fix tests not awaiting addLIveEvents
* Fix handling of thread roots in eventShouldLiveIn
* Fix types
* Fix tests
* Fix import
* Stash thread ID of relations in unsigned to be stashed in sync accumulator
* Persist after processing
* Revert "Persist after processing"
This reverts commit 05ed6409b35f5e9bea3b699d0abcaac3d02588c5.
* Update unsigned field name to match MSC4023
* Persist after processing to store thread id in unsigned sync accumulator
* Add test
* Fix replayEvents getting doubled up due to Thread::addEvents being called in createThread and separately
* Fix test
* Switch to using UnstableValue
* Add comment
* Iterate
To make it easier to track down where to-device messages are getting lost,
add a custom property to each one, and log its value. Synapse will also log
this property.
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.
* Support call room type from MSC3417
Signed-off-by: Robin Townsend <robin@robin.town>
* Make it more clear that call room type is unstable
Signed-off-by: Robin Townsend <robin@robin.town>
* Add group call events to EventType
Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>
* Use EventType instead of a const
Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>
* Make logging around sending group call member state event a bit better
Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>
* Fix m.calls elements being null
Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>
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
MSC: https://github.com/matrix-org/matrix-doc/pull/3089
Includes part of MSC3088 (room subtyping): https://github.com/matrix-org/matrix-doc/pull/3088
The NamespacedValue stuff is borrowed from the Extensible Events implementation PR in the react-sdk as a useful thing to put here. When/if the MSCs become stable, we'd convert the values to enums and drop the constants (or keep them for migration purposes, but switch to stable).
This flags the whole thing as unstable because it's highly subject to change.
Michael Weimann