* Fix issue with sentinels being incorrect on m.room.member events
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Simplify change
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Add test
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
---------
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* WIP support for state_after
* Fix sliding sync sdk / embedded tests
* Allow both state & state_after to be undefined
Since it must have allowed state to be undefined previously: the test
had it as such.
* Fix limited sync handling
* Need to use state_after being undefined
if state can be undefined anyway
* Make sliding sync sdk tests pass
* Remove deprecated interfaces & backwards-compat code
* Remove useless assignment
* Use updates unstable prefix
* Clarify docs
* Remove additional semi-backwards compatible overload
* Update unstable prefixes
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Fix test
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Add test for MSC4222 behaviour
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Improve coverage
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Fix tests
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Tidy
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Add comments to explain why things work as they are.
* Fix sync accumulator for state_after sync handling
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Add tests
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Revert "Fix room state being updated with old (now overwritten) state and emitting for those updates. (#4242)"
This reverts commit 957329b218.
* Fix Sync Accumulator toJSON putting start timeline state in state_after field
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Update tests
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Add test case
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
* Iterate
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
---------
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Co-authored-by: Hugh Nimmo-Smith <hughns@matrix.org>
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
Co-authored-by: Timo <toger5@hotmail.de>
* Fix room state being updated with old (now overwritten) state and emitting for those updates.
* remove timestamp condition
Add configuration for toStartOfTimeline
* fix timeline tests
* only skip event adding if event_id and replaces_state is set.
* fix room tests
* test skipping insertion
* rename back to lastStateEvent
* store if a state is at the start of a timeline in the RoomState class
* make `isStartTimelineState` a `public readonly` and fix condition.
* Attempt a potential workaround for stuck notifs
* Remove TODOs
* Fix backwards logic about server support for MSC3981 in fetchEditsWhereNeeded
* Check for lack of MSC3981 server support before calling insertEventIntoTimeline
* If no parent event is found, insert purely based on timestamp
* Mark temporary methods as internal
* feature detection code for thread list api
* fix bug where createThreadsTimelineSets would sometimes return nothing
* initial implementation of thread listing msc
* tests for thread list pagination
* 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
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.
