UIA live gate times out (GetFirstChild 0x80131505) after overview-lane Worktrees click

[coneilen]

Describe the bug
In validate.ps1 -Task windows-shell, the Native UI Automation live gate (Tools/windows/uia-live-gate.ps1) fails. A UIA TreeWalker.GetFirstChild call times out with 0x80131505 (UIA TimeoutException) after about 65 s. This happens right after the gate clicks the Worktrees overview lane (call site around uia-live-gate.ps1 lines 3270–3290; walker around line 1471). The shell process stays alive and keeps responding to Win32 messages; its last log line is "Returned to project graph". All other windows-shell steps passed in the same run: unit suites, smoke/stress, two-shell handoff, tray contracts and tray live tests.

It reproduced twice: once in the full validation run, and once in a standalone run of uia-live-gate.ps1.

To reproduce

1. Clone to a short path (for example C:\gc; see the MAX_PATH issue), at commit 59ebed1.
2. Bootstrap, then run pwsh -NoProfile -File Tools\windows\validate.ps1 -Task windows-shell -SwiftExecutable $env:GRAPHCODE_SWIFT633.
3. The UIA live gate fails at the Worktrees lane check with the timeout above.

Expected behavior
The gate completes. If the shell's UIA provider is blocked, for example by the UI thread waiting during the worktrees view transition, it should respond within the UIA timeout.

Environment

• Commit 59ebed1, Windows 11 Enterprise 26200 x64, interactive desktop session
• Swift 6.3.3, Zig 0.15.2

Additional context

• Root cause unknown: either a product hang in the accessibility provider or the UI thread during the Worktrees transition, or something specific to this desktop environment. Start by capturing a dump of graphcode-windows.exe during the 65 s window and checking whether the UI thread is blocked inside the UIA provider (WM_GETOBJECT handling) or in worktree loading.
• The evidence sandboxes (C:\gc\.build\tmp\gu-*) are local to the reporting machine only.
• Per AGENTS.md, the related parity-ledger rows stay Partial until this passes live.

[coneilen]

Status audit — 2026-10-01

Classification: needing evidence. Recommendation: keep open. Confidence: medium-high.

The gate still captures the Worktrees fragment, clicks the overview lane, and walks the previously captured element (uia-live-gate.ps1). Get-DirectChildren calls TreeWalker.GetFirstChild synchronously; the script deadline cannot bound a native UIA call that blocks for about 65 seconds, and the retry classifier has no explicit TimeoutException/0x80131505 treatment.

Counter-evidence exists: full hosted windows-shell integration runs passed after the report on #547 and #568. Those successes establish intermittency/environment dependence, not a targeted fix or diagnosis.

Remaining acceptance criteria: rerun current main repeatedly on the reporting Windows 11 profile; capture a timeout dump; distinguish stale-element/gate behavior, shared-desktop contention, and product provider/UI-thread deadlock; add a non-vacuous targeted regression with positive counts; or document a bounded current-main non-reproduction matrix before closure.

Preview priority: P1 qualification evidence. Escalate as a product blocker only if the dump shows an ordinary UI-thread/provider deadlock.

[coneilen]

Attribution update — 2026-10-01

Classification: product-attributed UI-thread starvation; dump evidence required before shared-source changes. The bounded harness branch remains #587, but it cannot pass required integration while the product blocks UI Automation during the Worktrees transition.

Exact-head CI evidence:

• the isolated worker reacquired worktrees immediately before the overview-lane click;
• after the click, five fresh worker processes timed out at 1000/1000/1000/1000/944 ms;
• every owned worker was killed and joined cleanly, proving the new boundary/cleanup works and the failure is not an unbounded child leak;
• no product accessibility files changed.

Current source attribution: App.applyOverviewLaneAction synchronously calls inspectWorktrees() from the mouse message handler. inspectWorktreesImpl performs WorktreeStatus.inspect inline; that path launches/waits for multiple Git children and recursively computes non-primary worktree sizes before publishing model/accessibility state. The UI/window thread therefore cannot service UIA while this work is in progress. This establishes UI-thread starvation, not yet a deadlock.

Required next evidence before editing shared App.zig / WorktreeStatus.zig:

• capture a full graphcode-windows.exe dump during the first post-click UIA_WORKTREES_READ_TIMEOUT;
• retain child-process inventory and command lines;
• confirm whether the UI thread is in applyOverviewLaneAction -> inspectWorktreesImpl -> WorktreeStatus.inspect, specifically runGit (Child.collectOutput/wait) or directorySize;
• if instead it is in gc_uia_update/provider locking, capture all threads and lock ownership.

This requires an authorized owned Windows desktop/process-dump flight. Until that evidence exists, do not broaden #587 into a speculative shared product fix or convert timeouts into PASS.

[coneilen]

Post-queue reconciliation PR #596 merged at main 41b4d9278f90b02c54262bf91d0410f710fef66a. This issue remains correctly open and queued. PR #587 is still harness-only evidence: bounded workers/cleanup pass, while required integration exposes product UI-thread starvation. The next action requires explicit authorization for an owned Windows desktop and a full graphcode-windows.exe process dump at the first timeout plus child inventory/command lines. No speculative App.zig/WorktreeStatus.zig change will be made without that evidence.

[coneilen]

Ownership claim for the authorized bounded Windows early-preview Worktrees guard: I am exclusively owning graphcode-windows/src/App.zig, graphcode-windows/src/main.zig, graphcode-windows/build.zig, Tools/windows/package.ps1, Tools/windows/Tests/Packaging.Tests.ps1, and a focused new Tools/windows/Tests/WorktreePreviewGuard.Tests.ps1 until the narrow product PR lands. Goal: release-candidate builds route every supported Worktrees action to the honest deferred message without calling inspection/reclaim/policy paths; normal developer builds retain existing behavior. This is Part of #560, does not close it, does not modify #587's harness files, and does not implement the speculative async fix.

[coneilen]

Reopened after #604 merged. The merged change is only the authorized bounded early-preview DeferAndGuard product guard; it does not resolve the underlying UI-thread starvation investigation or remove the dump requirement. #560 remains open.