CI flake: PersistentAgentModeMCPReadFileConnectionTests/testAgentOwnedWorktreeContentSearchCarriesPhysicalCoverageAndPreservesFullSelections fails intermittently on shards 3/4

[moonray]

Symptom

RepoPromptTests.PersistentAgentModeMCPReadFileConnectionTests/testAgentOwnedWorktreeContentSearchCarriesPhysicalCoverageAndPreservesFullSelections (Tests/RepoPromptTests/MCP/Control/PersistentAgentModeMCPReadFileConnectionTests.swift:796, assertion at :804) fails intermittently on the Build and Test CI shards, then passes on re-run / on other PRs.

Failure

PersistentAgentModeMCPReadFileConnectionTests.swift:796: error: -[RepoPromptTests.PersistentAgentModeMCPReadFileConnectionTests testAgentOwnedWorktreeContentSearchCarriesPhysicalCoverageAndPreservesFullSelections] : XCTAssertEqual failed: ("Optional([RepoPrompt.LineRange(start: 10, end: 17, description: nil), RepoPrompt.LineRange(start: 27, end: 29, description: nil), RepoPrompt.LineRange(start: 34, end: 34, description: nil)])") is not equal to ("Optional([RepoPrompt.LineRange(start: 6, end: 10, description: nil), RepoPrompt.LineRange(start: 20, end: 24, description: nil), RepoPrompt.LineRange(start: 30, end: 34, description: nil)])"

The content search returns a different (but plausible) set of matching line ranges than the expected coverage slices.

Evidence this is a flake (not a deterministic regression)

Across the last ~30 failed CI runs (Jul 6–8), this same test fails with the identical signature on 4 unrelated branches, spanning shard 3 and shard 4:

Run	Date	Branch	Shard
28786487861	Jul 6	wt/issue-390-fable-investigation	3
28790765740	Jul 6	feat/history-duration-threshold	3/4
28928694335	Jul 8	wt/build-process-storm-investigation	3/4
28955810559	Jul 8	fix/ci-flake-420	4

Same test, same :796/:804, byte-identical actual vs expected LineRange values each time, on different PRs built against main → non-deterministic. (The last run is from PR #430, where it was the only failure — the PR's own target test, AgentRunWorktreeStartTests/...testProductionCapture..., passed there.)

Likely cause

The result is a content-search line-range set that differs from the expected slices under some ordering/timing. PersistentAgentModeMCPReadFileConnectionTests is built around fragile concurrency machinery — the file references "the deterministic late-ingress race" and requires "Fixture slice ingress must be quiescent before installing the deterministic late-ingress race." The flake is consistent with fixture-slice ingress / content-search coverage not being fully quiescent when the assertion runs.

Impact

• Blocks otherwise-green PRs on shards 3/4 and forces manual re-runs.
• Erodes the CI signal — same class of disruption as CI flake: AgentRunWorktreeStartTests/testProductionCapturePreservesBoundStoredSelectionInsteadOfCanonicalUI fails intermittently on shard 4 #420.

Suggested investigation

• Stabilize the content-search line-range result around fixture-slice ingress quiescing (explicit await/drain before asserting), or make the assertion tolerant of equivalent physical coverage.
• If the race is inherent, make the test deterministically resilient (deterministic setup + explicit await) rather than timing-dependent — same approach taken for CI flake: AgentRunWorktreeStartTests/testProductionCapturePreservesBoundStoredSelectionInsteadOfCanonicalUI fails intermittently on shard 4 #420.

Tracking

Not currently listed in the flakes meta issue #425. (Filing without labels — filer lacks label permission. A maintainer please add e.g. bug / area:agent-mode / flaky and link from #425.)

[moonray]

Investigation findings (parking this — please read before re-investigating)

Looked into this to write a fix. Bottom line: root cause is pinned to an area, but it does not reproduce locally, so a verifiable fix needs CI-side data. Parking for now to avoid duplicated effort.

What the test checks

• Test body is assertWorktreeSearchPhysicalCoverage(fixture:) (PersistentAgentModeMCPReadFileConnectionTests.swift:664); failing assertion at :796/:804.
• Writes a fixture file with WATCHER_(BEGIN|MIDDLE|END)_ANCHOR_9F3A7C at lines 4/15/27 → content search (context_lines: 2) stores slices originalRanges = [2-6, 13-17, 25-29].
• Edits the file: +4 lines at top, +3 mid (idx 13), −2 (idx 26-27). Anchors move to lines 8/22/32 → a correct slice-rebase yields expectedRanges = [6-10, 20-24, 30-34]. The test waits on waitForPendingSliceRebasesAndCaptureFence then asserts.

The flake

Observed [10-17, 27-29, 34-34]. That value is neither the clean rebase ([6-10,20-24,30-34]) nor the stale/identity skip (originalRanges). So it's a genuinely garbled mapping produced from a wrong oldText/newText read mid-race — not a missing await.

Where the race lives (multi-path slice-rebase system)

SliceRebaseEngine.rebase is called from three sites in WorkspaceFilesViewModel.swift:

1. computeSliceRebaseConsumer — engine call at :12652 (hidden-session path; oldText from sliceRebaseSourceText :12628 using a sticky sliceRebaseSourceSnapshot + an mtime tolerance; newText from stableSliceRebaseSnapshot :12880, a 3-retry readValidatedContentSnapshot with no on-disk validation).
2. Direct active-tab call at :1809 — the path this test exercises.
3. A third call at :12883.

The garbled output points to the active-tab path (:1809) reading oldText/newText mid-race under CI scheduling/load.

Reproduction

• Does not reproduce locally. Focused test passes 30/30 isolated (and 1/1 with diagnostics attached). Like CI flake: AgentRunWorktreeStartTests/testProductionCapturePreservesBoundStoredSelectionInsteadOfCanonicalUI fails intermittently on shard 4 #420, it only fails under CI hosted-runner conditions, so there is no local oracle and I can't satisfy the "fixed = validation passes" bar on a fix.

What I tried + left behind

• Built DEBUG instrumentation to log oldText/newText fingerprints + stored vs computed ranges on divergence. First placement (computeSliceRebaseConsumer) didn't fire because the test uses the :1809 path. Reverted — the worktree branch fix/ci-flake-434 is clean at current main (7360ea85), unpushed.

Recommended next step (whoever picks this up)

• Ship a DEBUG-only instrumentation PR covering all three engine sites (:1809, :12883, :12652) so the next CI flake prints the exact oldText/newText that produced the garbled ranges. That yields the precise input combo → a verified fix. (The branch fix/ci-flake-434 is available as a starting point.)
• Alternative: reproduce under CI-like parallel test load.

Status: open / parked. Not actively being worked.