From b5a29a5c1975e705eea5655324cf4c987a71a9e7 Mon Sep 17 00:00:00 2001 From: Abir Abbas Date: Tue, 29 Sep 2026 15:51:44 -0400 Subject: [PATCH 1/2] session: wait for both parts to start before landing them in the park test TestAParentHandedADivisionBeforeItStartedOpensOnTheReportsAndNotOnTheWait counted the parts the test's runner had seen right after the parent parked. A part reaches that runner on a goroutine of its own, and the parent parks on the parts it has outstanding, not on their runners having started, so on a loaded CI box the park came first and the test read one part (#1674's gate on fc7feb003). It now waits for both. Co-Authored-By: Claude Opus 5.5 (1M context) --- internal/session/task_park_test.go | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/internal/session/task_park_test.go b/internal/session/task_park_test.go index 5d7ed08bfc..0e53ac08ff 100644 --- a/internal/session/task_park_test.go +++ b/internal/session/task_park_test.go @@ -673,12 +673,18 @@ func TestAParentHandedADivisionBeforeItStartedOpensOnTheReportsAndNotOnTheWait(t // One at a time, each landed only once the parent is back on its park, so the // last report is the one that wakes it and every earlier one is already // counted when it does. - partsMu.Lock() - landing := append([]*TaskNode(nil), parts...) - partsMu.Unlock() - if len(landing) != 2 { - t.Fatalf("%d parts were admitted, want the two that were proposed", len(landing)) - } + // + // BOTH PARTS ARE WAITED FOR, NOT COUNTED AT THE PARK. A part reaches this + // test's runner on a goroutine of its own ([TaskGraph.runFrontier]), and the + // parent parks on the parts it has outstanding, not on their runners having + // started; on a loaded machine the park came first and CI read one part. + var landing []*TaskNode + waitFor(t, "both proposed parts to start", func() bool { + partsMu.Lock() + defer partsMu.Unlock() + landing = append(landing[:0], parts...) + return len(landing) == 2 + }) for index, part := range landing { if index > 0 { // Past the park the previous landing was made against, so this one From fe47789b8ed7906285e2ec069c631e1795422d0d Mon Sep 17 00:00:00 2001 From: Abir Abbas Date: Tue, 29 Sep 2026 15:52:49 -0400 Subject: [PATCH 2/2] changes: #1676 entry Co-Authored-By: Claude Opus 5.5 (1M context) --- .../changes/unreleased/1676-park-test-parts-race.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 docs/changes/unreleased/1676-park-test-parts-race.md diff --git a/docs/changes/unreleased/1676-park-test-parts-race.md b/docs/changes/unreleased/1676-park-test-parts-race.md new file mode 100644 index 0000000000..7be42ddb10 --- /dev/null +++ b/docs/changes/unreleased/1676-park-test-parts-race.md @@ -0,0 +1,13 @@ +--- +kind: fixed +title: the park test waits for both parts to start instead of counting them at the park +pr: 1676 +surface: [engine] +invalidates: [] +--- + +TestAParentHandedADivisionBeforeItStartedOpensOnTheReportsAndNotOnTheWait counted +the parts its runner had seen at the moment the parent parked. A part reaches that +runner on a goroutine of its own, and the parent parks on the parts it has +outstanding rather than on their runners having started, so on a loaded CI box the +park came first and the test read one part. It now waits, bounded, for both.