Remove cancel optimization for packageQuery caller #1472
Merged
Conversation
This file contains 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.
There is currently no way to remove the callbacks from the context which means the callbacks can continue to be fired after the cancel has caused the coroutine to return if the coroutine does not wait for the context to finish. This triggers a crash. In the packageManagement case, it always waits for the context to finish, but in the packageQuery case it tried to optimize that away. It would be best to eventually figure out how to bring the quicker cancel back, so I'll file a bug, but for now removing that optimization so that it no longer fails is the first priority. Cancel in the packageQuery case will now also wait until the context is finished. The operation will be marked as status == Cancelled, even though it may have still run to completion (either successfully or with an install\download failure). This is built in behavior for async operations that can't be changed, and already happens for packageManagement callers calling Cancel during the Install phase (which cannot be cancelled).
Microsoft Reviewers: Open in CodeFlow