Work around runspacepool deadlock

[rjmholt]

PR Summary

Fixes #1297.

Ensures we don't access the CommandInfo.ParameterSets property on PackageManagement cmdlets, which can cause a deadlock for us due to the parallel invocation and they way these cmdlets implement their dynamic parameters.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

[rjmholt]

Worth noting that the mandatory parameter logic here is pretty flawed (I haven't changed it from the original). It takes a list of all the mandatory parameters of the cmdlet and checks to see that at least one was supplied.

But:

• There could be a parameter set specified by a provided non-mandatory parameter which has no mandatory parameters
• There could be multiple mandatory parameters in a given parameter set

Parameter binding is hard and rather than trying to fix the logic here, any attempt to fix it should be more general-purpose. But nobody seems to have complained about this yet, so I doubt it's actually a huge issue.

[rjmholt]

It's something I'd like to fix in an external library and reuse in PSSA, PSES and a few other places

[bergmeister]

Is it possible to have a simpler test case with a less complex file (either instead or additionally)?

[bergmeister]

Thinking of the problem on a higher level: We've only discovered that Packagemanagement cmdlet can cause this behaviour. What if more get discovered? It would be good to also have a global setting to disable the runspace pool caching. Is this issue a blocker for a release of a newer version of the vs code ps extension (which would implicitly start to ship with PSSA 1.18.1)? Do we want to have a 1.18.2 release (I would not mind as some useful commits like e.g. actionable error messages for settings files and various formatter fixes/enhancements have gone in already).

[bergmeister]

Please have a look at the build, there is a compilation error when compiling against net452

[rjmholt]

Please have a look at the build, there is a compilation error when compiling against net452

Bugger, can't use Array.Empty<T>() after all

[rjmholt]

Is this issue a blocker for a release of a newer version of the vs code ps extension (which would implicitly start to ship with PSSA 1.18.1)?

Yes it is. Ideally I'd like to address this issue and area more fully, but for now just trying to unblock.

Is it possible to have a simpler test case with a less complex file (either instead or additionally)?

So far this is the only good repro I've found in PSSA. Even then it's not 100%, but better than nothing.

What if more get discovered?

We've seen this in PSES as well and known about it for some time. It's because PkgMgmt does some extremely unusual threaded things to generate its dynamic parameters. Given that we haven't found any other cases and that this is caused by such a strange implementation, my feeling is thst the right approach is:

• Hotfix for PackageManagement in PSSA (this can remain in, since old versions of PackageManagement will be out there in use)
• Fix the issue in PackageManagement (which is more involved, and can't be relied upon to get to everyone)
• See if the mechanism allowing this to happen can be fixed in PS 7
• Possibly add more configurability to PSSA

[bergmeister]

In the meantime the PSES build could pin 1.18.0 in the call to Save-Module if you want to be able to quicker release an update to the extension before PSSA re-releases?

[bergmeister]

Looks good to me.
Just one question out of curiosity: If not re-using a runspacepool does not cause the problem (if I've read the issue correctly), would it not be simpler to just have an option on GetCommandInfoLegacy to not re-use the runspace pool for the queried command only when the command is one of the Packagemanagement ones?

[rjmholt]

If not re-using a runspacepool does not cause the problem (if I've read the issue correctly), would it not be simpler to just have an option on GetCommandInfoLegacy to not re-use the runspace pool for the queried command only when the command is one of the Packagemanagement ones?

I thought about that, but:

• I feel like using the runspace pool is a legitimate thing to do
• We want the performance benefit of using it and doing it this way only makes things faster
• I feel it's uglier to poke a hole in the command info API than to work around the problem at the call site
• The deadlock itself is complicated enough that I'm not totally convinced that avoiding the runspace pool will totally fix the problem, unlike avoiding the problem path for the PackageManagement cmdlets

[JamesWTruher]

@bergmeister - I see the signoff for this but I just want to be sure before I merge it.

[bergmeister]

@JamesWTruher I'm still happy with it to be merged, Rob's answer was satisfactory. I don't have any concerns.