Using Derby/Racer, an issue we've stumbled upon is that sometimes when having two queries, A and B, on two different pages (A and B), some of the results when moving from page A to B on a client side rendering causes from query B are undefined. More specifically, some of the doc data in undefined/non-existing. This is quite difficult to reproduce, because it's quite dependant on the computer speed it seems. Further, at the moment I unfortunately don't have a repro case I can run, so I can't verify my potential solution (or even check if what I think is the cause is the cause).
Anyway, I've done some digging and it seems that when removing docs there can be a lot of other things pending before the actual removal happens, thus causing a race condition. In other words, The data/docs from query A might be removed after query B. If the results of B overlap somehow with query A. Thus, we need to check for this when doing the actual removal.
I made a gist based upon version 32 of share/lib/client/doc.js which might fix this issue: https://gist.github.com/cjblomqvist/6f40a5cddf2b7d140c34
Basically I added _wantDestroy as a state property (so you can easily find my changes by searching for that string in the gist) which I check for when doing the actual removal of data, since it might be the case that we want to cancel the removal if we have a new query that want to keep the doc.
I'm far from sure it fixes it properly though. In particular, I'm concearned with what happens if the old contexts aren't removed. I hit my ceiling of knowledge of Share and time to look further into it (in particular since I don't have a test scenario to run locally), so I left it there. You should probably look into it though, I know many people have had problems with this using Derby.
Using Derby/Racer, an issue we've stumbled upon is that sometimes when having two queries, A and B, on two different pages (A and B), some of the results when moving from page A to B on a client side rendering causes from query B are undefined. More specifically, some of the doc data in undefined/non-existing. This is quite difficult to reproduce, because it's quite dependant on the computer speed it seems. Further, at the moment I unfortunately don't have a repro case I can run, so I can't verify my potential solution (or even check if what I think is the cause is the cause).
Anyway, I've done some digging and it seems that when removing docs there can be a lot of other things pending before the actual removal happens, thus causing a race condition. In other words, The data/docs from query A might be removed after query B. If the results of B overlap somehow with query A. Thus, we need to check for this when doing the actual removal.
I made a gist based upon version 32 of share/lib/client/doc.js which might fix this issue: https://gist.github.com/cjblomqvist/6f40a5cddf2b7d140c34
Basically I added _wantDestroy as a state property (so you can easily find my changes by searching for that string in the gist) which I check for when doing the actual removal of data, since it might be the case that we want to cancel the removal if we have a new query that want to keep the doc.
I'm far from sure it fixes it properly though. In particular, I'm concearned with what happens if the old contexts aren't removed. I hit my ceiling of knowledge of Share and time to look further into it (in particular since I don't have a test scenario to run locally), so I left it there. You should probably look into it though, I know many people have had problems with this using Derby.