Probably related issue on EXA : element-hq/element-x-android#3790

if a user's state changes and it is not in the timeline

@erikjohnston When does this happen? If someone changes their display name for example, the membership state event will show up in the timeline. And if the membership change happened outside of the range of the timeline_limit, then we are talking about a limited: true sync where this new logic doesn't apply anyway.

Is this targeting a scenario where some state comes over federation from some time ago which updates the current state but isn't in the timeline? (not sure this is even a thing because it will still get a recent stream_ordering which should make it come down /sync)

Probably related issue on EXA : element-hq/element-x-android#3790

@ganfra What's your exact theory for how this problem contributes to that issue?

To clarify this a bit: the original reported issue was:

1. There is a request to join (a knock membership event) from Alice. This appears in the required_state and is taken into account by the client, and Alice's membership is updated.
2. Bob accepts/declines the request to join (so he invites/kicks Alice from the room). This membership change appears in the timeline, but not in the required_state, probably because the sender of those events (Bob) is not the member whose membership changed (Alice).
3. Some other client of Bob doesn't receive any new state event in required_state, so it still thinks Alice's membership is knock, instead of invite/leave.

Technically, this could be also solved by processing the state events in the timeline, but since those are not guaranteed to be up to date it could easily lead to inconsistencies in the clients.

@jmartinesp Perfect description! That makes a lot more sense 👌

So basically, we just need to fill in this FIXME

I've made the changes with some tests in #17947 🚀

Technically, this could be also solved by processing the state events in the timeline, but since those are not guaranteed to be up to date it could easily lead to inconsistencies in the clients.

Correct choice 👍 Only rely on what the homeserver is telling you through required_state.