Repository navigation
PBGitWindowWiringTests times out waiting for the revision list #669
Description
PBGitWindowWiringTests fails on CI when the wait added in #644 runs out its 30 second ceiling:
GitXTests/PBGitWindowWiringTests.m:117: error: -[PBGitWindowWiringTests testTheSidebarHandedOutIsTheOneOnScreen]
: ((revisionList.isUpdating) is false) failed - the revision list is still walking the repository
Three occurrences since #644 landed on 2026-09-15, out of 67 workflow runs:
| run | date | branch | failing test | duration |
|---|---|---|---|---|
| 35327115860 | 2026-09-18 | warn-on-submodule-drift | testTheSidebarHandedOutIsTheOneOnScreen | 60.9s |
| 35235620710 | 2026-09-17 | master | testTheFocusedSidebarNamesTheBranchItHasSelected | 30.8s |
| 35013281396 | 2026-09-15 | worktree-lookup-off-the-draw-path | testTheFocusedHistoryListNamesTheBranchItHasSelected |
All three failed on build (26.3, macos-26, arm64). The Intel job has never failed this way. The failing test method differs each time, so this is the fixture's revision list failing to settle rather than any one test being wrong.
The durations give it away: 30.8s is one wait reaching the ceiling, 60.9s is two.
Where it comes from
#644 fixed #643 by waiting for the walk to finish rather than racing it. The wait is called from -setUp (line 104) and again from -tearDown (line 123):
- (void)waitForTheRevisionListToSettle
{
PBGitHistoryList *revisionList = self.windowController.repository.revisionList;
NSDate *limit = [NSDate dateWithTimeIntervalSinceNow:30];
while (revisionList.isUpdating && [limit timeIntervalSinceNow] > 0)
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.01]];
XCTAssertFalse(revisionList.isUpdating, @"the revision list is still walking the repository");
}That turned a crash into a bounded wait, but the condition #643 described is still present: on a loaded runner the walk does not finish. Closing #643 as completed was premature.
Worth measuring before changing anything
-tearDown calls [revisionList cleanup] and then waits. If cleanup does not actually stop a walk that is already in flight, the wait can only ever run out the full 30 seconds, and raising the ceiling would achieve nothing except slower red builds. Logging isUpdating and the elapsed time at both call sites would settle that.
Raising the timeout is the obvious move and probably the wrong one until that is known.
Activity
goneng commentedon Sep 19, 2026
A fourth occurrence, and this one is about as clean a demonstration as the CI can give.
Commit
b90c2b85was open as two pull requests at once, so it ran twice, starting in the same minute:build (26.3, macos-26, arm64)Same commit, same workflow, same runner image, opposite results. The failure is this issue again:
60.7 seconds is two 30 second waits running out, in
-setUpand again in-tearDown.That makes four occurrences, all on
macos-26, arm64, never on Intel, and a different test method each time:Four different methods in the same class points at the fixture's revision list rather than at any one test, which is what the original report in #643 said too.