Share FunctionInfo and execute it with $using when using `ForEach-Object -Parallel` causes session state corruption

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

This is reported by internal MSFT folks. Quote the emails content below:

Write-Host sometimes undefined with ForEach-Object -Parallel.

Due to networking issues, I can’t grab my actual code, but I wrote code along the lines of:

function f1
{
    param([string]$i)
    if (Test-Path $i) { return $i }
    # do something
    if ($i-eq "bad")
    {
        Write-Host "something is wrong!"
        return $null
    }

    return $i
}

function get-inputs
{
    return @("foo", "bar", "bad", "good")
}

function invoke-processInputs
{
    $inputs = get-inputs
    $f1Func = Get-Command -Name "f1"
    $job = $inputs | ForEach-Object -AsJob -ThrottleLimit 2 -Parallel {
        $output = & $using:f1Func $_
        if ($output -eq $null)
        {
            # do something
        }
    }

    #do some status reporting on the job...
    while ($job.State -eq "Running") { write-host "running..." ; start-sleep 1 }
    Wait-Job -Id $job.Id
    Remove-Job -Id $job.Id
}

My actual input set has 100+ entries and some of them essentially trigger the bad case (through a bunch of network stuff). What’s super confusing is that I both see the actual output (the “something is wrong” in this example) as well as “The term ‘Write-Host’ is not recognized as the name of a cmdlet…” error too. I’ve also seen the Test-Path give the same error. Those both seem… wrong

I expect there’s something about the parallel foreach that I’m messing up, but I’m not sure what here.

Expected behavior

Write-Host should work fine

Actual behavior

Run into error:
The term 'Write-Host' is not recognized as the name of a cmdlet…

Error details

Not available

Environment data

This is all on pwsh 7.2 (GA, nothing internal)

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

Visuals

N/A

[SeeminglyScience]

If it is an unambiguous match we could do it automatically. Simply banning these constructs is bad UX. It would be much easier for users to use intuitive explicit constructs and the Engine would convert this into the correct implementation.

I fear that if that’s done automatically it will lead to a lot of confusion about why the function can’t access the state it previously could. While the error isn’t great UX, it happens at design time and is instantly clear what is wrong. Plus the work around makes it a lot easier to understand that it won’t work exactly the same.

[iSazonov]

Instead, share the AST among those Runsapce’s. In your case, it would be something like this:

If it is an unambiguous match we could do it automatically. Simply banning these constructs is bad UX. It would be much easier for users to use intuitive explicit constructs and the Engine would convert this into the correct implementation.