execution: MaxProcesses admits processes before capacity checks and ignores low configured limits

[PierrunoYT]

Version / branch / commit

Source-reviewed on main at 99721c7.

OS and environment

Linux amd64; Go 1.26.6. AI-assisted source audit checked against the implementation. The proposed capacity regression cases below have not been executed.

Steps to reproduce

1. Create ProcessManager with MaxProcesses=1.
2. Start one long-lived process and leave it running.
3. Start a second long-lived process and inspect live processes and the manager snapshot.
4. Separately, exercise simultaneous starts at capacity with a fake transport and a victim whose termination is delayed or fails.

Expected behavior

A positive configured capacity is enforced before launching another OS process, or documented and represented separately if it is only a completed-history retention target. Admission failures must not leave untracked child processes.

Actual behavior / source evidence

Start:113-160 starts the transport at line 127 before store performs its capacity check.

store and processToPruneLocked:361-393 insert the new process before terminating a live victim outside the lock. If all existing processes are live and there are eight or fewer, processToPruneLocked returns nil even when MaxProcesses is 1. Concurrent starts can select the same not-yet-terminated victim and each admit a replacement.

terminate:563-571 ignores the kill error, so eviction is not proof that capacity has been recovered.

Suggested fix / regression coverage

Reserve capacity atomically before startTransport, release the reservation on launch failure, and reject or wait when full. If preserving eviction semantics, reserve a unique victim and account for termination completion/failure before admitting replacements. Cover MaxProcesses=1, concurrent starts, and failed termination.

Verification

The full existing non-race suite and focused race tests for internal/execution passed during the audit. This is a source-supported admission/limit defect, not a reported Go data race or an executed resource-exhaustion reproduction.

[Vasanthdev2004]

Confirmed on main, with one part narrowed.

What reaches production: Start launches the process before store checks capacity, so a slot is never reserved; concurrent starts at capacity can pick the same live victim, which stays in the map until it exits, so each of them admits a replacement; and terminate drops the kill error, so an eviction is not proof the slot came back.

The low-limit part is real in the API but not reachable from config today. The only production manager is execution.NewProcessManager(execution.ProcessManagerOptions{}) in internal/tools/exec_command.go, so MaxProcesses is always the default 64 and the eight-live floor in processToPruneLocked never binds below it.

Approving for the reservation, the victim race and the ignored kill error. The floor can stay as it is unless the fix makes the limit strict anyway.