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.

8/8 Scenarios PASS 20 xUnit · 15 Pester Phase 1 + Phase 2 RFC pending

Source Files

+173

Lines Added

Requirements

8/8

Scenarios Pass

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

Navigate This Report

⚙

New Public API

PSInvocationSettings.Timeout + Stop(TimeSpan) with migration guide

📝

Source Changes

6 files, +173/−13 lines, before/after comparison

⬡

Execution Flows

4 SVG diagrams: pool timeout, Phase 2, Stop(TimeSpan), parallel stop

Specification

11 formal requirements with SHALL statements and test mappings

▶

Interactive Scenarios

Step through all 8 adversarial scenarios with typed output

⎘

PR Body

Lean ~60-line PR description ready to paste into GitHub

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.