6.3 Remote Execution Infrastructure

Audit action classes for remote execution, route contract gaps to repairs or explicit local exceptions, and require remote-only proof before fleet acceptance.

Preserve Bazel's execution-platform and toolchain intent through backend-specific pool routing, then prove compatible placement and visible rejection.

Select reversible remote-execution candidates from a versioned workload contract, client/REAPI/backend evidence, and must-have requirements with explicit exit conditions.

Reconstruct one successful remote attempt from portable Execute/Operation evidence and backend-owned queue, lease, executor, and completion observations.

Map a remote action onto deployable roles, typed paths, operating owners, and failure domains without confusing backend topology with REAPI.

Classify each remote-execution state population by its declared recovery contract and measured rebuild cost, then prove the plan through component-loss tests.

Follow remote inputs through availability checks and outputs through CAS upload and ActionResult publication without publishing a dangling or incomplete result.

Use this when already matchable actions queue, starve, or bypass apparently available compatible capacity.

Use this when ensuring an action runs in the promised environment without inheriting files, processes, credentials, or residue from another action.

Choose and qualify the worker's eager or lazy presentation of an already-available Merkle/CAS input closure.

Use this when choosing which outputs Bazel downloads while ensuring tests, IDEs, CI, humans, and later consumers can still obtain required files.

Use this when executor count or average CPU looks healthy while compatible action classes still queue or starve.

Use this when remote actions are slow or fail and recovery must avoid retry storms, duplicate accepted results, lost evidence, or untrusted outputs.

Use this when several teams or trust domains share remote execution without reading, poisoning, leaking, or starving one another.

Place remote actions, complete AC/CAS data, matchable capacity, and output consumers across regions, then define safe partition and region-loss behavior.

Use this when reducing duplicate work or tail latency without accepting two results or wasting uncontrolled capacity.

Use this when draining workers, changing component versions or images, rolling back, or restoring service after a planned transition fails.

Use this when a successful staging build exists but you need to decide whether the whole deployment is safe and operable for production workloads.

Use a local VM-backed REAPI executor to expose host assumptions, exercise remote-only client paths, and share AC/CAS state without treating one machine as a production RBE deployment.