Skip to content

Show a window when the focus outruns its move - #864

Open
SimonCropp wants to merge 1 commit into
mainfrom
viewer-focus-outruns-move
Open

Show a window when the focus outruns its move#864
SimonCropp wants to merge 1 commit into
mainfrom
viewer-focus-outruns-move

Conversation

@SimonCropp

Copy link
Copy Markdown
Member

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.

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.
@SimonCropp SimonCropp added this to the 20.2.2 milestone Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant