Show a window when the focus outruns its move - #864
Open
SimonCropp wants to merge 1 commit into
Open
Conversation
A failing pair whose diff tool is the viewer goes over as two messages on two connections: the move to the tray's piper port, then a focus to whoever owns the queue, naming the key that move was tracked under. Nothing orders them. PiperClient is fire and forget - it reports that the bytes went out, not that the tray read them - and the tray takes that connection on a task of its own, reads it to the end, and walks up from the target looking for a solution before the entry is visible to anything asking. The focus is in flight through all of it. ViewerMessageHandler.Focus refuses a key it cannot find and raises nothing, and AddDiff discarded that refusal and reported AlreadyRunningAndSupportsRefresh regardless. Losing the race was a run where the pair reached the tray menu and no window ever opened, and a second run - where the same key was still tracked from the first - where one did. Which is how it was reported: the diff tool does not show, then on the next run it does. Intermittent, and likeliest on the first move for a path, where the solution walk is uncached and a run with many failing snapshots has the thread pool busiest. A refused focus now falls through to ViewerVerb.Diff, which tracks and raises in a single message to a single process, so there is no order left to get wrong. Its tracking is keyed on the received file like the piper move's, so whichever lands second updates the one entry. That also covers the arrangement where a viewer owns the queue while a tray runs and the focus can never find the key, because that viewer does not know the tray's files: the pair is tracked on both sides there rather than shown by neither. DiffRunnerViewerFocusRaceTest holds the race open rather than trying to win it. A real PiperServer takes the move and never gives it to the tracker, which is what the real one looks like for as long as it is still reading. A move the tray has already tracked is pinned too, since it must stay a plain focus: a Diff would replace the entry and lose the exe and arguments the piper send carries. DiffRunnerViewerMoveTest gains a FakeViewer to answer its focus, having pointed at a dead port before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A failing pair whose diff tool is the viewer goes over as two messages on two connections: the move to the tray's piper port, then a focus to whoever owns the queue, naming the key that move was tracked under. Nothing orders them. PiperClient is fire and forget - it reports that the bytes went out, not that the tray read them - and the tray takes that connection on a task of its own, reads it to the end, and walks up from the target looking for a solution before the entry is visible to anything asking. The focus is in flight through all of it.
ViewerMessageHandler.Focus refuses a key it cannot find and raises nothing, and AddDiff discarded that refusal and reported AlreadyRunningAndSupportsRefresh regardless. Losing the race was a run where the pair reached the tray menu and no window ever opened, and a second run - where the same key was still tracked from the first - where one did. Which is how it was reported: the diff tool does not show, then on the next run it does. Intermittent, and likeliest on the first move for a path, where the solution walk is uncached and a run with many failing snapshots has the thread pool busiest.
A refused focus now falls through to ViewerVerb.Diff, which tracks and raises in a single message to a single process, so there is no order left to get wrong. Its tracking is keyed on the received file like the piper move's, so whichever lands second updates the one entry. That also covers the arrangement where a viewer owns the queue while a tray runs and the focus can never find the key, because that viewer does not know the tray's files: the pair is tracked on both sides there rather than shown by neither.
DiffRunnerViewerFocusRaceTest holds the race open rather than trying to win it. A real PiperServer takes the move and never gives it to the tracker, which is what the real one looks like for as long as it is still reading. A move the tray has already tracked is pinned too, since it must stay a plain focus: a Diff would replace the entry and lose the exe and arguments the piper send carries. DiffRunnerViewerMoveTest gains a FakeViewer to answer its focus, having pointed at a dead port before.