Many debugger client operations are done asynchronously: they require communicating with the server or other resources, and should not lock up the UI. If the user operates interacts with the UI and navigates to a new page, resumes/pauses a thread, or changes the selected thread, the client operation might no longer be relevant. If it continues to make changes to the redux state, it can corrupt the state with old/invalid information. This has caused several problems lately that were very difficult to track down, and it would be nice to have a general way of dealing with this situation.
The attached patch is a WIP in this direction. The reducer pause state contains a Context object, which encapsulates the core debugger state: how many navigations have occurred, which thread is currently selected, and how many times that thread has paused or resumed. This gives enough information to be able to classify operations as obsolete in several different ways: if a navigation has occurred, if the selected thread has changed, or if the thread has changed its pause state. The idea here is that when an operation is initiated (from a component usually, or from an unsolicited server message) we get the current context, and check that context later on against the current one as the operation proceeds to see if it is irrelevant. This patch adds some middleware to automatically perform these checks on dispatched actions which have a 'cx' property, and ignore them if so.
The interface used here needs some more work, particularly around how we specify the conditions under which an operation is obsolete. The patch is also pretty minimal so far in actually using contexts, so they might evolve in other ways as the uses get filled in. I'm posting this now because this is pretty exploratory and it would be good to get feedback as things proceed.