You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Occasionally, with subscribed queries using a sort+limit and query polling, we're seeing the ShareDB server emit a diff list that temporarily causes the ShareDB client results to contain the same id twice, for an instant in time. Immediately afterwards, the Share server emits a diff to clean up the duplicate id, but this behavior causes the Racer query's idMap to become incorrect and unload docs from its model that are still subscribed to by Share. (I'll send a patch to make Racer defensive against this issue.)
This appears to only happen when the same client that's subscribed to the query goes and issues an op that would change the query's sort order. An example of the diff lists received by the Share client - note than an item is inserted at index 3 and then immediately removed:
After the first diff list is processed by the Share client, here's what the Share query results' ids are, as well as the last diff event emitted in the Share client's _handleDiff - note that the inserted item at index 3 has the same id as the item at index 0:
Occasionally, with subscribed queries using a sort+limit and query polling, we're seeing the ShareDB server emit a diff list that temporarily causes the ShareDB client results to contain the same id twice, for an instant in time. Immediately afterwards, the Share server emits a diff to clean up the duplicate id, but this behavior causes the Racer query's
idMap
to become incorrect and unload docs from its model that are still subscribed to by Share. (I'll send a patch to make Racer defensive against this issue.)This appears to only happen when the same client that's subscribed to the query goes and issues an op that would change the query's sort order. An example of the diff lists received by the Share client - note than an item is inserted at index 3 and then immediately removed:
After the first diff list is processed by the Share client, here's what the Share query
results
' ids are, as well as the last diff event emitted in the Share client's_handleDiff
- note that the inserted item at index 3 has the same id as the item at index 0:Index 0 is the new "correct" place for the item, based on the sort order. The move after the remove shuffles the results into the correct order.
I'm not sure if this is sharedb or sharedb-mongo, but I'm filing it here in sharedb-mongo for now as the Share code appears fine at first glance.
Example of a Racer query that we see will eventually trigger the issue:
The text was updated successfully, but these errors were encountered: