Question: Can optimistic dispatchEvents be wrapped in Meteor.defer

[znewsham]

I've been seeing some method results be delayed unnecessarily by redis-oplog synchronously parsing the optimistic events from mutations. In one specific (particularly bad) case, my 1 second method call was delayed by an additional 5 seconds to allow redis to process these calls.

In the above scenario, I have two users viewing the same (fairly large) table. The table has approximately 300k rows, of which only 100 are shown at a time.

User 1 is filtering + sorting + limiting, using an index prefix. User 2 triggers some functionality that removes a record in this collection. The result of user 2's method call is delayed until redis-oplog re-queries the selector that user 1 is viewing - in a large collection, this can take some time.

Is there any reason that the optimistic functionality could not be handled in a Meteor.defer? This would allow the triggering method call to return immediately

[theodorDiaconu]

@znewsham we can do it like that, however it will not work with optimistic updates. This was the reason it was done in sync.

[znewsham]

@theodorDiaconu - I don't think I understand - user 1 doesn't need optimistic UI, since they didn't trigger the update - and potentially user 2 is viewing a much smaller dataset.

Is it possible to detect which observerhandles are associated with the requesting connection, and do those sync, and the handles that are associated with other connections, do those async?