Command exception when installing a plugin

[devblackops]

Expected Behavior

The plugin (module) is installed without error

Current Behavior

When running !install-plugin --name <pluginname>, the command throws the exception below. This appears to be an innocuous error as the plugin is installed fine. Running !get-plugin --plugin <pluginname> shows the newly installed plugin and executing the plugin commands work correctly.

Command Exception:

System.Management.Automation.StopUpstreamCommandsException: System error.
   at Microsoft.PowerShell.Commands.SelectObjectCommand.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()

Steps to Reproduce (for bugs)

Run the following command to install a plugin (module) from the PSGallery

!install-plugin --name nameit

[michaeltlombardi]

In my experience, this was only happening with plugins not grabbed from the gallery as of the last update - locally installed plugins wrote an error, plugins downloaded and installed from the gallery did not.

[devblackops]

This looks to be related to this: http://stackoverflow.com/questions/25314741/stop-execution-of-cmdlet-in-processrecord.

Select-Object -First $n throws a non-public exception called StopUpstreamCommandsException.

That is by design as that is how Select-Object -First $n can stop the pipeline when $n is reached. I was using Select-Object -First 1 to grab the first instance of Get-Module $name -ListAvailable | Sort-Object Version -Descending to get the latest version of a module.

PoshBot is surfacing that exception when it probably shouldn't. I'll have to dig into that.

To fix this particular issue with Install-Plugin I switched to @(Get-Module $name -ListAvailable | Sort-Object Version -Descending)[0]. In my tests, this exception is no longer shown.

This is still a deeper issue as I imagine other functions that use Select-Object -First $n will surface the exception as well. The problem is most likely in the CommandExecutor class where the commands are executed and output (including the Error stream) is collected.

[michaeltlombardi]

That looks like a pretty good solution! We're referencing these changes correct?

Should this be closed by those updates and mention made in one of the developer-documentation guides?

[devblackops]

This can probably be closed but another issue that mentions the larger problem should be created. I'd like to squash the problem as I think it it could be a cause of frequent issues going forward as people write perfectly valid plugins and come up against this.