[HalRiveria-Bot]

What was wrong

Invoke-PkRunspaceJobs workers had three problems with where they ran and what they inherited:

• Wrong folder. Workers started in the PowerShell process's working directory, not the caller's current location. A relative path in a worker cmdlet, such as Get-Content .\data.txt, looked in the wrong folder.
• Folder changes leaked between jobs. Runspaces are reused from job to job, so a job that changed folder moved every later job on that runspace.
• Variables leaked between jobs. The worker ran at the runspace's global scope, so a variable a job set carried over to the next job. That includes $ErrorActionPreference: a worker that set it to 'Stop' made later jobs on the same runspace crash on errors they would otherwise only have reported.

Reproduced on Windows PowerShell 5.1 and PowerShell 7.

What changed

Each job now does two things, in one script:

1. It moves to the caller's current location. That's the real folder behind a New-PSDrive drive, and the same folder Start-PkProcess uses by default since Start programs in the current location, and read program paths as PowerShell does #22.
2. It runs the worker in a scope of its own, with the job's values passed as its parameters.

Why one script. A Set-Location statement added ahead of the worker (AddCommand(...).AddStatement()) left the pool runspace's pipeline incomplete: it still hadn't finished after 10 s on both 5.1 and 7. So the move and the worker are a single script, and the worker runs as & { <worker> } @values. The prefix shares the worker's first line, so error line numbers still match the worker's own code. I checked that against main.

If the folder disappears mid-run, a job runs wherever its runspace already is, without reporting an error.

Docs: the README worker section and the Invoke-PkRunspaceJobs help describe this. The README also notes that relative paths in .NET calls still follow the process's working directory, as they do outside workers.

Compatibility:

• A worker that relied on state carried over from an earlier job on the same runspace no longer gets it. That was never documented.
• Inside the worker, $MyInvocation now describes a scriptblock call rather than a top-level script.

Testing

• New harness section X, 4 checks:
  • three jobs on one runspace each start in the caller's location, even though each one changes folder;
  • a relative path in a worker cmdlet resolves against the caller's location;
  • a variable and $ErrorActionPreference set by one job aren't there in the next;
  • from a New-PSDrive drive, workers start in the real folder.
• Against the kit on main: all 4 fail (4 FAILED, 257 passed). The failures show jobs 2 and 3 starting in C:\WINDOWS and inheriting EAP=Stop.
• With the change: ALL PASSED (261 assertions) on 5.1 and 7.

🤖 Generated with Claude Code