System.Management.Automation · Engineering Report
Hosting API: Bounded Wait & Timeout
Two-phase fix replacing every unbounded WaitOne()/Wait() in the PowerShell hosting API
with bounded alternatives, plus new opt-in public API for callers that need predictable failure modes.
6
Source Files
+173
Lines Added
11
Requirements
8/8
Scenarios Pass
01
The Problem
Applications that embed PowerShell (services, hosts, plugins) have no way to bound how long the engine takes to respond. Six separate wait points could hang indefinitely:
| Location | Old code | What hangs |
|---|---|---|
PowerShell.Invoke() | WaitOne() | synchronous single-runspace invocation |
pool.BeginGetRunspace | WaitOne() | all RunspacePool slots occupied |
BatchInvocationContext | Wait() | multi-statement batch invocation |
LocalPipeline.Stop() | WaitOne() | pipeline thread won't die |
StopPipelines() (sequential) | loop of Stop() | N pipelines × unbounded stop time |
LocalConnection.Close() | WaitOne() | runspace or job throttle close |
02
Navigate This Report
Zero regression risk.
All new timeout behaviour is opt-in. Any code that does not set
PSInvocationSettings.Timeout
or call Stop(TimeSpan) is byte-for-byte identical to the pre-fix code path —
including the single-runspace Invoke() fast path which uses no Task.Run,
no timer allocation, and runs on the same thread.
03
Related Contributions
This PR is part of a batch of 5 contributions to PowerShell/PowerShell:
| PR | Title | Type |
|---|---|---|
| #27027 | Hosting API bounded-wait timeouts (this PR) | Engine API |
| #27033 | UUID v7 for New-Guid | Enhancement |
| #27034 | Fix -Switch:$false for Get-Culture / Get-Location | Bug fix |
| #27035 | PVS-Studio static analysis fixes | Code cleanup |
| #27078 | Fix Verify Markdown Links CI workflow | CI fix |
PRs #27033, #27034, #27035, and #27078 have a companion review site: ps-contrib-review.pages.dev