Meteor.subscribeWithPagination and handle.stop race condition

help
1

Hello! We have a project using percolate:paginated-subscription. I’ve noticed a problem with a pattern like this:

  • on page 1 we subscribing to a subset of users by some condition. Say, there are 100+ users in this subscription.
  • on page 2 we want to show paginated list of users. Only first 15 of them. We achieve it by subscribing to paginated subset of users on page 2

When we switch from page1 to page2, we run code like this:

userSubscription.handle.stop()
Meteor.subscribeWithPagination('users', 15)

So when we reach the page2, we see about 150 users on the second page. How to avoid this?

As far as I understood from the docs, when we do stop on subscription, it takes some time for it to actually stop by sending DDP ‘removed’ messages from server to client.

If i add a delay of 150-300ms between stop and subscribe, it doesn’t help. The delay of 1-2s helps, but it is not good from the UX viewpoint.

What can we do? What actually happens?

2

I don’t know if this will necessarily answer your question, but I believe what you see is latency compensation in the Meteor pub/sub system. To understand this myself I created a little demo a while ago to visualize this.