I believe I have spotted a bug with the lazy_loaded_members_cache cache, which essentially tracks 'what users have we recently sent down to the client' in order to reduce the size of the response body.
The cache is mutated, to mark lazy-loaded member(s) as having been sent down to the client, during the course of building the response, before the response is 'acknowledged' by a subsequent /sync.
On many homeservers, there is a 2-minute response cache which would replay the correct response without computation.
But when this response cache is disabled, or after 2 minutes, a repeated /sync request would receive a response with the relevant lazy-loaded members omitted even though they should be included.
End result would appear to be a desync in the memberships sent down to the client, though after a period of inactivity (to let the cache expire) and seeing the member again, it would be resent.
I believe I have spotted a bug with the
lazy_loaded_members_cachecache, which essentially tracks 'what users have we recently sent down to the client' in order to reduce the size of the response body.The cache is mutated, to mark lazy-loaded member(s) as having been sent down to the client, during the course of building the response, before the response is 'acknowledged' by a subsequent
/sync.On many homeservers, there is a 2-minute response cache which would replay the correct response without computation.
But when this response cache is disabled, or after 2 minutes, a repeated
/syncrequest would receive a response with the relevant lazy-loaded members omitted even though they should be included.End result would appear to be a desync in the memberships sent down to the client, though after a period of inactivity (to let the cache expire) and seeing the member again, it would be resent.