Bug: sync `rooms.joined.state` overlaps with `rooms.joined.timeline` #361

New issue

Open

opened 2024-05-09 18:14:20 +00:00 by olivia-fl · 1 comment

olivia-fl commented

2024-05-09 18:14:20 +00:00

(Migrated from github.com)

The spec for the sync endpoint says that the rooms.joined.state field should be

Updates to the state, between the time indicated by the since parameter, and the start of the timeline (or all state up to the start of the timeline, if since is not given, or full_state is true).

Instead of updates between since and the start of the timeline, we're returning updates between since and the end of the timeline.

Steps to reproduce

Create a room and generate several state events (room topic changes are convenient for this)
Make a call to /v3/sync without a since parameter
Observe the set of state events included in rooms.joined.$your_room.timeline and compare it to the set of state events included in rooms.joined.$your_room.state. Some events that are present in timeline are also present in state.

Notes

The spec includes this block with an explanation of the reasoning behind this design:

An early design of this specification made the state list represent the room state at the end of the returned timeline, instead of the start. This was unsatisfactory because it led to duplication of events between the state list and the timeline, but more importantly, it made it difficult for clients to show the timeline correctly.

In particular, consider a returned timeline [M0, S1, M2], where M0 and M2 are both messages sent by the same user, and S1 is a state event where that user changes their displayname. If the state list represents the room state at the end of the timeline, the client must take a copy of the state dictionary, and rewind S1, in order to correctly calculate the display name for M0.

The spec for the sync endpoint says that the `rooms.joined.state` field should be > Updates to the state, between the time indicated by the since parameter, and the start of the timeline (or all state up to the start of the timeline, if since is not given, or full_state is true). Instead of updates between `since` and the start of the timeline, we're returning updates between `since` and the end of the timeline. ### Steps to reproduce 1. Create a room and generate several state events (room topic changes are convenient for this) 2. Make a call to `/v3/sync` without a `since` parameter 3. Observe the set of state events included in `rooms.joined.$your_room.timeline` and compare it to the set of state events included in `rooms.joined.$your_room.state`. Some events that are present in `timeline` are also present in `state`. ### Notes The spec includes this block with an explanation of the reasoning behind this design: > An early design of this specification made the state list represent the room state at the end of the returned timeline, instead of the start. This was unsatisfactory because it led to duplication of events between the state list and the timeline, but more importantly, it made it difficult for clients to show the timeline correctly. > > In particular, consider a returned timeline [M0, S1, M2], where M0 and M2 are both messages sent by the same user, and S1 is a state event where that user changes their displayname. If the state list represents the room state at the end of the timeline, the client must take a copy of the state dictionary, and rewind S1, in order to correctly calculate the display name for M0.

olivia-fl commented

2024-05-09 22:02:20 +00:00

(Migrated from github.com)

This causes issues for sliding-sync-proxy. See here.

NOTE: The proxy works fine with Dendrite and Synapse, but it doesn't work well with Conduit due to spec violations in the state of a room in /sync. Running the proxy with Conduit will cause more expired connections (HTTP 400s) when room state changes, and log lines like WRN Accumulator.filterToNewTimelineEvents: seen the same event ID twice, ignoring.

This causes issues for `sliding-sync-proxy`. See [here](https://github.com/matrix-org/sliding-sync?tab=readme-ov-file#usage). > NOTE: The proxy works fine with Dendrite and Synapse, but it doesn't work well with Conduit due to spec violations in the state of a room in /sync. Running the proxy with Conduit will cause more expired connections (HTTP 400s) when room state changes, and log lines like WRN Accumulator.filterToNewTimelineEvents: seen the same event ID twice, ignoring.