Just spotted another race condition we need to deal with. When live indexing is enabled, the indexing system runs two queries: a non-live query to pick up the old message, and then a live query for anything new. There is an opportunity between those two (however small) for a message to be posted between the non-live query and the live query which could be missed by the index.
There's going to be one of these in the graph builder test system as well, but that one's a little less critical since it's just in a test system and as such won't impact users. But it could cause failures. Really low priority for that, though.
I'm not sure what the best way to do this is with the architecture we've got, especially without introducing other race conditions. Maybe we could log the last-seen sequence number in the non-live query, feed that to Margaret, and then patch up Margaret's live functionality so it can go back through the log and feed forward from there?
Just spotted another race condition we need to deal with. When live indexing is enabled, the indexing system runs two queries: a non-live query to pick up the old message, and then a live query for anything new. There is an opportunity between those two (however small) for a message to be posted between the non-live query and the live query which could be missed by the index.
There's going to be one of these in the graph builder test system as well, but that one's a little less critical since it's just in a test system and as such won't impact users. But it could cause failures. Really low priority for that, though.
I'm not sure what the best way to do this is with the architecture we've got, especially without introducing other race conditions. Maybe we could log the last-seen sequence number in the non-live query, feed that to Margaret, and then patch up Margaret's live functionality so it can go back through the log and feed forward from there?