Problem
AdoptExpectedChildProcessAsync (GameProcessManager.cs) checks the discovery deadline before the
clean-exit grace period elapses, so the two can race.
When a launcher exits cleanly without spawning a child, the loop records launcherExitedAt and
keeps polling for ProcessConstants.LauncherExitGracePeriodMs (1s) to cover the
spawn-then-enumerate window. But the deadline check runs in the same iteration. If a caller sets
GameLaunchConfiguration.ExpectedChildDiscoveryTimeout shorter than that grace period, the
deadline wins and the failure is reported as:
Launcher did not start {name} within 0.5s.
instead of the accurate:
Launcher exited without starting {name}.
Wrong diagnosis, not wrong outcome — both fail the launch. It matters because the timeout message
sends someone looking for a slow launcher when the launcher already exited.
The default timeout is SpawnedChildDiscoveryTimeoutMs (10s), well above the 1s grace, so this
only surfaces for callers passing a short explicit timeout. Tests do exactly that.
Approach
Either clamp the effective deadline so a recorded clean exit always gets its grace period, or drop
the grace period and accept the spawn-then-enumerate race. Worth confirming which failure the
message should favour when both conditions are genuinely true.
Introduced by #343, present in release/alpha-4.
Problem
AdoptExpectedChildProcessAsync(GameProcessManager.cs) checks the discovery deadline before theclean-exit grace period elapses, so the two can race.
When a launcher exits cleanly without spawning a child, the loop records
launcherExitedAtandkeeps polling for
ProcessConstants.LauncherExitGracePeriodMs(1s) to cover thespawn-then-enumerate window. But the deadline check runs in the same iteration. If a caller sets
GameLaunchConfiguration.ExpectedChildDiscoveryTimeoutshorter than that grace period, thedeadline wins and the failure is reported as:
instead of the accurate:
Wrong diagnosis, not wrong outcome — both fail the launch. It matters because the timeout message
sends someone looking for a slow launcher when the launcher already exited.
The default timeout is
SpawnedChildDiscoveryTimeoutMs(10s), well above the 1s grace, so thisonly surfaces for callers passing a short explicit timeout. Tests do exactly that.
Approach
Either clamp the effective deadline so a recorded clean exit always gets its grace period, or drop
the grace period and accept the spawn-then-enumerate race. Worth confirming which failure the
message should favour when both conditions are genuinely true.
Introduced by #343, present in
release/alpha-4.