pwsh shell on windows - failures not detected since Runner 13.9

Summary

In a customer call (🎫 link for GitLab team members) relating to the Powershell Core (pwsh) variation of the shell executor, it was highlighted that errors from pwsh on Windows (PowerShell core executor/shell) were no longer being trapped as job failures.

I suspect this relates to the change to use STDIN - !2715 (merged)

Steps to reproduce

See reproduction project https://gitlab.com/bprescott-support/testing/zd206695-win_ps_chars

Customer provided reproduction code for two issues. The Erroractionpreference stage is their code reproducing this, with the same code running on 13.8, 13.9, and 13.10, 13.11 runners.

The Error2 code is a further reproduction of this - illustrated using another job they'd provided for a different bug. This illustrates the problem with a different powershell error.

Similarly, four jobs which run on the four runner versions.

In both stages the two 13.8 jobs show as failed in the pipeline but the other jobs, running the same code, do not.

Actual behavior

pwsh code fails, the job is successful.

Expected behavior

pwsh code fails, the job fails.

Relevant logs and/or screenshots

https://gitlab.com/bprescott-support/testing/zd206695-win_ps_chars/-/pipelines/294628867

Environment description

I have a Windows 10 laptop with multiple runners set up as services. PowerShell-7.1.3-win-x64.msi is installed with the PATH populated.

All are configured with the defaults except for check_interval

concurrent = 1
check_interval = 13

[session_server]
  session_timeout = 1800

[[runners]]
  name = "foo"
  url = "https://gitlab.com"
  token = "bar"
  executor = "shell"
  shell = "pwsh"

Used GitLab Runner version

13.9.0, 13.10.0, 13.11.0

Possible fixes

Based on this suggestion in the GitHub issue, by wrapping our scripts like the following (preserving line-endings in userscript):

$__pwshcode = {userscript}

& $__pwshcode

we are able to have Powershell execute the script as a single block, mimicking the behavior of passing a file, regardless of whether we're using the shell executor or the Docker executor.