Fix WSLC exec hang on fast runc failure (e.g. invalid user/group)

[benhillis]

Summary

Fixes a hang in wslc container exec when the exec'd process fails before runc forks it (e.g. wslc container exec -u root:badgid id). The wslc client hangs forever instead of returning exit code 126 and the "unable to find group badgid" error.

Root cause

WSLCContainerImpl::Exec polls Docker's exec inspect endpoint after StartExec to learn whether the user process is running or has already failed. The Running branch was guarded by state.Pid.has_value():

if (state.Running && state.Pid.has_value()) {
    control->SetPid(state.Pid.value());
    break;
}

This guard is meaningless because Docker's wire schema (backend.ExecInspect in moby) declares Pid as a non-nullable Go int that is 0 until runc forks the user process — so the JSON response always contains "Pid": 0 and nlohmann always deserializes that as optional<int>(0) with has_value() == true.

When runc fails before forking (invalid user/group, missing binary, etc.), Docker briefly reports {"Running": true, "Pid": 0, "ExitCode": null} in the small window between logging the error and running its deferred cleanup that sets Running=false, ExitCode=126. The polling loop:

1. Accepts Pid=0 as a valid PID
2. Calls SetPid(0)
3. Breaks out of the loop
4. Returns the process handle to wslc
5. wslc waits on the exit event forever, because Docker never emits an exec_die event when the user process never spawned (containerd's process-exit event stream never fires)

Forensics

Confirmed via process dumps and ETL trace from a failing CloudTest run:

• DockerExecProcessControl in the wslcsession dump has m_pid = 0 (with has_value() == true) and m_exitedCode unset; its exit event was never signaled.
• ETL trace contains exactly four events for the failing exec id: exec_create, exec_start, dockerd ERROR "unable to find group badgid", and one GET /exec/{id}/json returning 200. No exec_die ever.
• Compare the previous test (NameGroupRoot) where the user process actually runs: exec_die is emitted normally.

Fix

Change InspectExec.Pid from std::optional<int> to plain int to match the wire format (Go int is non-nullable), and check state.Pid > 0 at the call site. With this change the loop continues polling on Pid=0; on the next 100ms iteration Docker has settled state and the existing ExitCode branch fires with the correct exit code 126.

ExitCode remains std::optional<int> because moby's backend.ExecInspect.ExitCode is *int (genuinely nullable).

Validation

The existing E2E test WSLCE2EContainerExecTests::WSLCE2E_Container_Exec_UserOption_InvalidGroup_Fails is the regression test for this bug. With the fix it should pass reliably; without it, it hangs until the test host is killed.

[benhillis]

Hit this test failure in the release pipeline - I suspect it's just a somewhat tight race window.

[OneBlue]

Great catch ! We might as also want to add assert that Pid > 0 in SetPid() to avoid getting hung if we ever hit something similar in the future