| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Looks like there are some Pester test failures that have nothing to do with this PR. |
Sorry, something went wrong.
|
Paul Higinbotham (@PaulHigin): Regarding the intermittent hang, my suspicion is that there is a timing issue with the initial handshake in MS-PSRDP, where the initial outgoing message from the client fires before the server starts actively listening for requests, at which point both client and server are waiting for communication from one another: the client waits for the server to respond, and the server waits for the client to tell it what to do. I believe this is an existing issue, not new, and it can probably be reproduced with the original set of APIs that MS-PSRDP supports. |
Sorry, something went wrong.
|
Paul Higinbotham (@PaulHigin) Thinking about this more, and reading through the code this morning, I'm convinced that the scenario I shared above is the root cause, and the issue I tripped on is related to issue #8012. Neither RunspaceState nor RunspacePoolState have a "Ready" state. They only have Opened, and they both of them do processing after they have entered the Opened state, which is the wrong thing to do when it comes to asynchronous processing. The test that hangs intermittently waits for the job to enter the Running state before using the new MS-PSRDP APIs, but jobs can enter a Running state before the listener is ready to receive requests in the remote runspace. When this happens, remote APIs invoked against the remote runspace will appear hung. This issue is not related to the changes in this PR, but this PR and the original test suite written to validate these changes exposed the issue. That should be handled separately, as an RFC according to the committee review of #8012, which should propose a solution for both Runspace and RunspacePool event handling to ensure that SDK users can build code that can know with confidence that the runspace they are accessing via the SDK is ready for them to use it asynchronously. I've added that RFC to my list of tasks to do, so that we can get that discussion started and resolve this problem for SDK users who do async processing with PowerShell. In the meantime, I just changed the Pester tests that use the new MS-PSRDP APIs such that they won't run until the runspace is truly ready. The easiest workaround I could come up with was to add a breakpoint and wait for the runspace to hit that breakpoint before using the APIs. Making this change allows me to run the tests over and over and over, and it never hangs. I'll commit that change in just a moment. |
Sorry, something went wrong.
|
FYI, the Codacy issue that is being flagged is a false positive. |
Sorry, something went wrong.
|
Any chance we can get some progress on the pending reviews here? As indicated, the Codacy issue is a false positive. This PR is good to go, just needs reviews finalized so that it can be merged. Other work is pending the merge of this PR. |
Sorry, something went wrong.
|
Kirk Munro (@KirkMunro) Thank you for your contribution! |
Sorry, something went wrong.
…process without BreakAll for PSES (PowerShell#10338)
|
🎉v7.0.0-preview.4 has been released which incorporates this pull request.:tada: Handy links: |
Sorry, something went wrong.
…process without BreakAll for PSES (PowerShell#10338)
| Back | FazBrowse Home | New Git URL |
PR Summary
PR Context
This PR is needed for "attach to process" debugging in PowerShell Editor Services.
It helps because:
Important details about this PR:
cc: TylerLeonhardt Paul Higinbotham (@PaulHigin) Steve Lee (@SteveL-MSFT)
PR Checklist