Powershell: Select-Object -First populates `-ErrorVariable`

[Jaykul]

Steps to reproduce

& {
    [CmdletBinding()]param()
    1,2,3,4 | Select -First 1
} -ErrorVariable Problems; 
$Problems |  Format-List * -Force

Expected behavior

There are no errors, so $Problems should be empty.

Actual behavior

$Problems has StopUpstreamCommandsException which Select-Object -First threw.

Environment data

Name                           Value
----                           -----
PSVersion                      6.1.3
PSEdition                      Core
GitCommitId                    6.1.3
OS                             Microsoft Windows 10.0.18353
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[vexx32]

sigh

We need a proper pipeline stop signal. This has been brought up before, and it really needs to be done. There are too many side effects from using a secret exception to do it.

[mossrich]

Also reported 11/2018: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/36081100-error-select-object-with-first-parameter-populat

This issue is also present in Powershell 4 and 5, but manifests as 'System error. '

PS > 1..2 | Select -First 2 -ErrorVariable X; $X | select *
1
2

RequestingCommandProcessor : Select-Object
Message : System error.
Data : {}
InnerException :
TargetSite : Void ProcessRecord()
StackTrace : at Microsoft.PowerShell.Commands.SelectObjectCommand.ProcessRecord()
at System.Management.Automation.CommandProcessor.ProcessRecord()
HelpLink :
Source : Microsoft.PowerShell.Commands.Utility
HResult : -2146233087

PS > $PSVersionTable.PSVersion

Major Minor Build Revision

---

4 0 -1 -1

[ericnelson]

This one bites you in really fun ways when using orchestration tools like RunDeck that strictly check the ErrorVariable of Invoke-Expression -ErrorVariable +myerr. Scripts run but the orchestration tools report failures. Quite a few refactors because of this.

[vexx32]

@SteveL-MSFT is there anything we can do about this one for ps7? I'm more than willing to put some work in here, but I'm not at all clear on where to start :(

[SteveL-MSFT]

@vexx32 It seems that this is not going to be a small fix that maintains backwards compatibility. As such, seems risky to take for PS7.

[vexx32]

Sure, but that will always be the case. Lots of little niggles like this all add up to a bit of an unfortunate mess in terms of error handling in PS. Joel B has several issues on various aspects of it, and all of them could potentially be breaking changes.

However, the behaviour is broken to begin with. If a major version isn't a time to fix these long-standing problems, when is? :slightly_smiling_face:

[SteveL-MSFT]

I agree this should be addressed, however, it's also been like this for probably ever. From a priority standpoint, it's not clear to me how many customers are actually affected by this.

[vexx32]

Definitely fair, I get that. I'm not asking for it to be solved yesterday, just if there are folks who might be familiar with the internals on your team, I'd appreciate some pointers on possible avenues for a solution / relevant code areas to be have a good chance of being able to put a solution in code. 🙂

[mossrich]

In case it helps with prioritization, this showed up as a post-implementation issue for multiple clients at my organization when an internal product upgrade was applied that introduced 'Select -First' in a deploy script. Wrapper scripts falsely reported the error variable being set as a deploy failure. I added a workaround that ignores errors with 'HResult = -2146233087' in the most urgent cases, but I know there are some clients who haven't yet encountered this issue and will eventually.
It seems safe to assume that no one is _depending_ on the error variable to be set in this scenario.
Thanks for whatever attention you can give to the solution. It may not help my clients who are unlikely to do a major version upgrade in the near future, but it certainly adds to the overall robustness of Powershell.

[SteveL-MSFT]

Looked into this and turned out to be simple

[msftbot[bot]]

:tada:This issue was addressed in #10840, which has now been successfully released as v7.0.0-preview.6.:tada:

Handy links:

• Release Notes