Fail the parallel run when a worker returns no result

[nohwnd]

Four files went into a Run.Parallel run on CI and three came back. The missing file was not failed, skipped or errored, it was not reported at all, and the run looked green with one test fewer than it should have had. Details and the CI log are in #3011.

Invoke-TestInParallel filters worker results to guard against stray pipeline output:

# Keep only well-formed worker results (defensive against stray pipeline output).
$results = @($results | & $SafeCommands['Where-Object'] { $_ -is [System.Management.Automation.PSCustomObject] -and $null -ne $_.PSObject.Properties['Containers'] })

That line cannot tell stray output from a worker that died before it returned its result object, and nothing afterwards compared the number of results to the number of files sent. A lost file was dropped as quietly as a stray string, and Sort-Object then put the survivors in discovery order, so the output looked like a normal shorter run.

Now the counts are compared after the filter, and a short result set throws and names the files that went missing. The worker's own error is already surfaced by Invoke-InRunspacePool, this says which file it cost us.

This does not depend on why the worker died, any worker that dies for any reason costs a whole test file. #3004 stopped one failing worker from aborting the results of the others, it did not check that every file came back.

The import race that killed the worker in the first place is the other half of #3011 and is not fixed here. I could not reproduce it locally in 288 staggered imports, 1600 worker imports across 200 real parallel runs, or 400 imports timed onto the five second validVerbs removal.

Tests

Added a test that hands Invoke-TestInParallel a runspace pool runner which drops one file's result, and asserts the run throws and names that file. Full local suite: 2915 passed, 0 failed, 3 skipped.

Fix #3011

🤖