-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialise: don't snapshot without create event #266
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect there are integration tests which do not ensure this.
in case someone is playing silly buggers
These rooms have invalid state snapshots, leading to correctness problems. The existence of such snapshots leaves us open to performance problems due to gappy state updates. We have prevented invalid state snapshots from being formed (#255, #266) in the future. The remaining hole is to discard existing invalid snapshots. Closes #256.
Str("room_id", roomID). | ||
Int("len_state", len(events)). | ||
Msg(errMsg) | ||
return fmt.Errorf(errMsg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have been a DataError. Otherwise the poller will end up retrying the same sync again and again.
Followup to #255. Prerequisite for #256.
We don't want there to be "bogus" snapshots without a create event. We used to create such snapshots if we were informed of a stray state event in a room timeline. #235 targeted on known occurrance; #255 stopped this more generally.
We noticed another way to create bogus snapshots today. Namely: if the first time the proxy saw a room it had a state block lacking a create event. We don't think Synapse has been sending us these (outside of a gappy sync, where it is expected). But let's err towards caution to try and keep the database sane.