fix: drop a player answer that belongs to a file no longer open - #103
Closed
xAlcahest wants to merge 3 commits into
Closed
fix: drop a player answer that belongs to a file no longer open#103xAlcahest wants to merge 3 commits into
xAlcahest wants to merge 3 commits into
Conversation
Owner
Author
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.
Summary
useVideoPlayerwrote every answer it got back, whatever file it was about. A command sent against the file that was open could still be in flight when the next one opened, and its refusal then set the player's error state, which puts a sentence on the status bar about a document nobody asked about. Each command now carries the open it belongs to, and an answer arriving with an older one is dropped instead of written.This was found by reading, while looking for the cause of BACKLOG N40, a check in
video-aspect.spec.jsthat fails on the CI runner and has never failed on this machine. The race is real on its own terms and the fix stands on its own. Whether it is what that check keeps catching is not proven and cannot be proven here: two attempts to reproduce it by taking the audio output away, which is the one difference the runner and this machine are known to have, did not reproduce it. That is written into N40 rather than implied.Changes
How to verify it by using the app
Verified on Linux: full gate green step by step, and the battery green at 34 spec files of 34. No new check: the race needs two opens to overlap, which the harness cannot drive through the chooser, and a check that cannot be made to redden is not a check.