element-hq / element-hq/synapse
Initial syncs being cached means you can get an outdated view of account data
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 600
- Avg merge
- 5d 22h
- Merged PRs (30d)
- 51
Description
This issue has been migrated from [#15162](https://github.com/matrix-org/synapse/issues/15162).
---
There are two problems with this:
- (1) it possibly betrays client expectations, that doing an initial sync will get them to 'correct' state immediately.
- (2) it means we don't apply the correct set of ignored users to the events received in the timeline of the initial sync. (For context: the server hides events sent by ignored users, when sending events to the client.)
This issue is causing https://github.com/vector-im/element-ios/issues/7387 — we *could* tell them to just do a zero-timeout incremental sync immediately but that feels like a hack and it wouldn't solve (2).
For (2), I wonder if we can just fetch the latest account data stream ID for the ignored users list, when doing an initial sync, and embedding it into the sync response cache token.
That way, the sync response cache entry will automatically be invalidated when the account data changes.
It's not a perfect solution since it only helps with ignored users, but it at least solves (2).
Problem (1) might be solvable through better documentation about the fact that clients should always incrementally sync after an initial sync if they want to guarantee they have the freshest data. Sliding sync might obviate these concerns anyway.
Contributor guide
Research direction
Start by tracing how initial sync responses are cached and how the ignored-users account data stream ID is obtained. Check whether account-data changes invalidate the relevant cache entry and whether initial-sync timeline events apply the current ignored-user list. Done means the outdated account-data view and ignored-user filtering problem are resolved, with the remaining freshness expectation documented if needed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100