Execute-PowerShell does not fork/create a new execution environment on each execution

I've been battling what I thought was an issue with a third-party tool but I now believe the root issue is with how BuildMaster handles Execute-PowerShell.

Occasionally if more then one execution simultaneously ran this tool via Execute-PowerShell some global state would appear to be shared and lead to misbehavior. I eventually 'solved' the problem by implementing a simple mutex to keep one and only one execution from occuring.

Fast forward to today when I was testing a change that was applied by setting an environment variable ie $Env:var = "blah" unfortunately this did not work so I removed the line from my plan and reran the stage. However, it was still showing the now removed behavior. Future troubleshooting proved that it was executing the plan, ie I broke it in a different way and that error was evident.

The I realized what was going on. It appears that when buildmaster runs Execute-PowerShell it is doing within the context of the BuildMaster process. So when I set my env variable it remained within process scope across plan executions. I confirmed this by setting a env in one plan and printing it in a completely different plan.

IMHO, this is NOT the implied expectation of Execute-PowerShell. Ie that every execution should be it's own process or at least have the environment reset.

Is this by design and/or should this be a bug?

Product: BuildMaster
Version: 5.7.3

This is by design, and works fine for 95% or more of the use cases.

The major benefit to in-process execution is performance; a new process/environment will often take longer to initialize the entire script to run, especially depending on the modules installed. This makes use of lots of small or inline scripts (like a $PSEval(...)) impractically slow.

The downside to this is, is that a "bad" PowerShell script can leak memory and cause the overall agent process to balloon. Of course, process environment variables are also shared... but this is much less common, as it is considered an anti-pattern to ps development. However, many scripts are directly translated directly from Linux bash, so the pattern comes through.

Anyways, we plan to solve this (and other shared-process problems) by allowing for agent process isolation. Basically, you will be able to do something like with isolation {...} and then all agents would spin up a new process to execute whatever is contained in the block.