There's a ShareDB issue where a subscribed ShareDB query can emit an insert event with an id that's already present in the result list. ShareDB then immediately emits an event (usually remove) to fix the duplication, but because the Racer query's idMap didn't keep track of id counts, it would mistakenly remove the id when the id's count went from 2 to 1. That causes the doc to become unloaded, since Racer uses the idMap to determine if any queries are subscribed to the doc.
The underlying ShareDB issue requires more investigation to fix, but Racer should still be defensive about it, especially since the issue results in Racer becoming internally inconsistent:
There's a ShareDB issue where a subscribed ShareDB query can emit an insert event with an id that's already present in the result list. ShareDB then immediately emits an event (usually remove) to fix the duplication, but because the Racer query's
idMap
didn't keep track of id counts, it would mistakenly remove the id when the id's count went from 2 to 1. That causes the doc to become unloaded, since Racer uses theidMap
to determine if any queries are subscribed to the doc.The underlying ShareDB issue requires more investigation to fix, but Racer should still be defensive about it, especially since the issue results in Racer becoming internally inconsistent: