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
Various smaller sliding sync fixes #1372
Conversation
7232f65
to
c267be8
Compare
Before we'd push one empty entry at a time, which lead to a lot of vecdiff updates pushed. With this we now only push one event after the entire operation set has been applied on the fresh or cold view.
2d071a2
to
6cc1e7d
Compare
…rocessing before stopping the loop
1749e08
to
b8fdbb1
Compare
27d33f5
to
e84341f
Compare
…thout positional update
e84341f
to
223b99f
Compare
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.
Look good, left a couple of nits.
@@ -167,154 +177,239 @@ mod tests { | |||
// index-based views don't support removing views. Leaving this test for an API | |||
// update later. | |||
// | |||
// #[tokio::test(flavor = "multi_thread", worker_threads = 4)] |
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.
What's up with this test? It seems to be the same one as further bellow with the same name, which is ignored instead of commented out.
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.
there is no commented-out one further below anymore. I removed the comment and instead opted for ignoring it for better visibility. This is probably a mixup in the history... the final result only has the ignored one.
@@ -491,10 +505,8 @@ impl SlidingSyncView { | |||
) -> Arc<StoppableSpawn> { | |||
let mut room_list = self.inner.rooms_list.signal_vec_cloned().to_stream(); | |||
Arc::new(StoppableSpawn::with_handle(RUNTIME.spawn(async move { | |||
loop { |
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.
grrr... leftover from a bad refactor that wasn't fully reverted: we still need this loop {
here ...caused stupid bug...
Various sliding sync fixes, providing tests where possible. ref #1359
Replace
event being triggeredlive
state only being set at the beginning of the next cycle and growing sync some times skipping beats. This changes the code to do a post-processing of the view-generator code after we've received the new update - based on the data of the update. Leading to one request less beforelive
being triggered and fixing beat-skipping..await
might get interrupted and thus processing of the results could fail. We can see in the logs that this happening and might cause gaps in the room list even. This has been fixed by switching to anAtomicBool
to inform the inner loop to stop after every iteration rather than cancelling the actualJoinHandle
.limited
flag) fixes the problem of gappy timelines when the room ran out of scope and came back in.