vscode: sidebar data (builders, backlog, PRs, etc.) intermittently disappears, then recovers on its own

[amrmelsayed]

Symptom

The Codev sidebar in VSCode intermittently loses all its rendered data while keeping its section headers intact. Affects every data-bearing section simultaneously:

• WORKSPACE — empty
• BUILDERS — empty (even with active builders running)
• PULL REQUESTS — empty
• BACKLOG — empty
• RECENTLY CLOSED — empty

The section chevrons still toggle expand/collapse correctly; the views just render no children. After some unknown interval (seconds to minutes), the data spontaneously returns without any user action — no refresh-click, no reload, no Tower restart needed.

Reproduces randomly. No known trigger pattern yet.

What this isn't

• Not "Tower is down" — the sections render their headers, which require the extension to be live; if Tower was unreachable the workspace would visibly show its connection-failure state.
• Not the cleanup-transient case in vscode: builder briefly appears under 'Uncategorized' area group after cleanup before disappearing #907 (where a terminated builder briefly appears under Uncategorized before disappearing). That bug shows wrong data; this one shows no data.
• Not the user collapsing groups — section headers themselves are visible and clickable. Even the data-bearing groups (like the area-group rows inside Builders) are absent, not just their children.

Suspected paths to investigate

Several shared mechanisms could produce this all-sections-empty pattern simultaneously:

1. overviewCache.getData() momentarily returns null/undefined. Every provider checks data presence and short-circuits to [] on a falsy value (e.g. BacklogProvider.rootChildren at views/backlog.ts:!data → return []). A single null read from the shared cache would empty every view at once.

2. SSE event delivery race. If connectionManager receives an empty overview frame, fires onDidChangeTreeData on every provider, then a subsequent frame arrives with the populated data — the tree would render empty during the gap. The recovery-after-N-seconds pattern is consistent with this (next normal overview poll arrives, providers re-fire with real data).

3. Tower-side empty-overview emit during a state transition. Builder cleanup, spawn, or migration could produce a moment where Tower's overview endpoint returns an empty/incomplete payload before the new state is committed. The extension would faithfully render whatever it receives.

4. A failed-fetch path that swallows the error and emits [] to consumers instead of holding the last-known-good data. The fact that headers persist (extension stays live) but children empty suggests provider data flow rather than connection loss.

What to capture next time it happens

To root-cause this properly, the next observed occurrence wants:

• VSCode Developer Tools console open during the event (Help → Toggle Developer Tools → Console tab) — look for any error/warning frames around the moment data disappears.
• Tower terminal output around that timestamp — any error/empty-overview log lines.
• Whether the disappearance correlates with any specific event (builder spawn, cleanup, PR merge, Tower restart, network blip, laptop wake-from-sleep, etc.).
• How long the empty state persists before recovery, and what action (if any) triggered the recovery vs. just waiting.

Acceptance (eventual fix)

• Identify which of the four suspected paths above (or some other) is the root cause.
• Either prevent the empty-data emission at its source (Tower or overviewCache), or have providers hold the last-known-good data when an empty/null frame arrives (so the UI doesn't flicker on transient empties).
• Add an integration test or a runtime invariant: "providers do not render an empty children array as a transient response to a single null/empty data update."

Out of scope

• Reworking how the sidebar communicates with Tower at the architectural level — this is a transient-state-handling bug, not a redesign.
• The cleanup-transient Uncategorized symptom (already tracked at vscode: builder briefly appears under 'Uncategorized' area group after cleanup before disappearing #907).