After macOS process ids wrap, the load gate's queue is no longer first-come-first-served and an old waiter can be starved by every new starter. On 2026-10-22 waiters started 19 s and 9 min earlier held pids 8034 and 12051 while hour-old waiters held 58628 and 73003. The fix for iss-2610161634043273 orders the queue by start time but counts a queued waiter as ahead only when it is ahead by start AND has the lower pid (internal/core/machineload/queue.go, queueOrder/queuedAhead), so after a wrap neither waits on the other; the open-moment stand-back in implement.WaitLoad (openLook, internal/core/implement/load_wait.go ~546) then yields to the lower pid, so the hour-old waiter stands back for each young low-pid starter until its backoffs run out or its timeout (8 h) ends, and a release-blocking preflight can be held all night.

After macOS process ids wrap, the load gate's queue is no longer first-come-first-served and an old waiter can be starved by every new starter. On 2026-10-22 waiters started 19 s and 9 min earlier held pids 8034 and 12051 while hour-old waiters held 58628 and 73003. The fix for iss-2610161634043273 orders the queue by start time but counts a queued waiter as ahead only when it is ahead by start AND has the lower pid (internal/core/machineload/queue.go, queueOrder/queuedAhead), so after a wrap neither waits on the other; the open-moment stand-back in implement.WaitLoad (openLook, internal/core/implement/load_wait.go ~546) then yields to the lower pid, so the hour-old waiter stands back for each young low-pid starter until its backoffs run out or its timeout (8 h) ends, and a release-blocking preflight can be held all night.

Grounds

• pursued: an earlier-started waiter is admitted before any later one whatever their pids, and a mutual wait with a pid-ordered waiter ends within WaitCrossedCap; a waiter held behind a later start, or a cycle of waits lasting past the cap while nothing else shuts the gate, would show it wrong