BatchPolicy (_released)

BatchPolicy Type

Namespace: ProcessKit
Assembly: ProcessKit.dll
Base Type: obj
All Interfaces: IEquatable<BatchPolicy> , IStructuralEquatable

How `Exec.outputAllWithPolicy` / `outputAllBytesWithPolicy` behave once any command in the batch produces an `Error` — a genuine run failure (`ProcessError`: couldn't start, timed out, was cancelled, exhausted its `Retry` budget, …), never a non-zero exit, which stays data under `Ok` exactly as it does for `outputString`/`outputBytes` themselves.

Union cases

Union case Description

Union case	Description
`CollectAll` Full Usage: `CollectAll`	Run every command to completion regardless of any other command's outcome, and collect every result in input order — the batch never short-circuits. What `Exec.outputAll` / `outputAllBytes` do, and the default `outputAllWithPolicy` / `outputAllBytesWithPolicy` fall back to when no policy is given a reason to differ.
`FailFast` Full Usage: `FailFast`	On the FIRST command whose result is an `Error`, stop starting any command still waiting for a concurrency slot and cancel every command already running — the same signal the batch's own `CancellationToken` sends, so no `IProcessRunner` needs special-casing to honour it: a command's own `Retry` policy sees an ordinary cancellation and stops retrying exactly as it would for the caller's own token. Every element of the batch still gets a `Result` in input order: - The triggering command keeps its own real error. - A command that already finished (success or failure) before the trigger keeps its own outcome — a `FailFast` batch is never rewritten retroactively. - A command still queued for a concurrency slot when the trigger fires never enters `capture` at all and becomes `ProcessError.Cancelled` — this one IS guaranteed. - A command already running when the trigger fires receives the same cancellation signal as the caller's own token, but keeps whatever result its own `capture` call returns — cancelling and finishing race like any other cancellation, so it is NOT guaranteed to become `Cancelled`; it may complete with its own success or failure first. - Two commands failing at nearly the same time is not a special case: whichever's `Error` is observed first triggers the cancellation (idempotent — a second trigger is a no-op), and both keep their own real errors, since both had already finished.

Full Usage: CollectAll

Run every command to completion regardless of any other command's outcome, and collect every result in input order — the batch never short-circuits. What `Exec.outputAll` / `outputAllBytes` do, and the default `outputAllWithPolicy` / `outputAllBytesWithPolicy` fall back to when no policy is given a reason to differ.

Full Usage: FailFast

 On the FIRST command whose result is an `Error`, stop starting any command still waiting for a
 concurrency slot and cancel every command already running — the same signal the batch's own
 `CancellationToken` sends, so no `IProcessRunner` needs special-casing to honour it: a command's
 own `Retry` policy sees an ordinary cancellation and stops retrying exactly as it would for the
 caller's own token. Every element of the batch still gets a `Result` in input order:

 - The triggering command keeps its own real error.
 - A command that already finished (success or failure) before the trigger keeps its own outcome
   — a `FailFast` batch is never rewritten retroactively.
 - A command still queued for a concurrency slot when the trigger fires never enters `capture` at
   all and becomes `ProcessError.Cancelled` — this one IS guaranteed.
 - A command already running when the trigger fires receives the same cancellation signal as the
   caller's own token, but keeps whatever result its own `capture` call returns — cancelling and
   finishing race like any other cancellation, so it is NOT guaranteed to become `Cancelled`; it
   may complete with its own success or failure first.
 - Two commands failing at nearly the same time is not a special case: whichever's `Error` is
   observed first triggers the cancellation (idempotent — a second trigger is a no-op), and both
   keep their own real errors, since both had already finished.

Instance members

Instance member	Description
`this.IsCollectAll` Full Usage: `this.IsCollectAll` Returns: `bool`	Returns: `bool`
`this.IsFailFast` Full Usage: `this.IsFailFast` Returns: `bool`	Returns: `bool`