Reset the interactive window using IInteractiveWindowOperations#52453
Reset the interactive window using IInteractiveWindowOperations#52453sharwell merged 1 commit intodotnet:mainfrom
Conversation
|
|
||
| public void Reset(bool waitForPrompt = true) | ||
| { | ||
| ExecuteCommand(WellKnownCommandNames.InteractiveConsole_Reset); |
There was a problem hiding this comment.
Why isn't this way stable? Is this actually hiding a bug where the user command won't be reliable?
There was a problem hiding this comment.
@tmat and I were not able to find a root cause looking through heap dumps all day. My best guess is we are somehow issuing the command at a point where IsResetting is true and it ends up getting dropped:
At least by calling the true underlying command we'll be able to see the task in future heap dumps.
There was a problem hiding this comment.
Hmm, ExecuteCommand doesn't return a failure if we try executing it when the command is unavailable?
There was a problem hiding this comment.
The documentation just says:
ExecuteCommandcannot execute commands that are currently disabled in the environment. TheBuildmethod, for example, will not execute while a build is currently in progress.
The method returns void and doesn't declare any exceptions.
I'd check the implementation but DTE...
|
|
||
| public void Reset(bool waitForPrompt = true) | ||
| { | ||
| ExecuteCommand(WellKnownCommandNames.InteractiveConsole_Reset); |
There was a problem hiding this comment.
Hmm, ExecuteCommand doesn't return a failure if we try executing it when the command is unavailable?
The previous implementation relies on using DTE to execute a named command. However, since it is not the purpose of these tests to cover invoking this command by name (a dedicated test could be created if desired), we modify the code to instead directly invoke the backing API for this command. This change reduces the likelihood that a failure in the commanding infrastructure leads to an obscure test failure.
Closes #52409