question/bug: Electron renderer can go blank after extension UI updates, especially after Plannotator plan review

[marcinkardas]

Operating system(s)

• Windows
• macOS
• Linux

What happened?

(@IgorWarzocha, mam wrażenie, że ten błąd mi się już przydarzył kilka razy przed pobraniem wczoraj zaktualizowanego repo z nowymi commitami. Mam widgety renderujące status subagentów / listę to-do, a teraz głównie dzieje mi się to po użyciu Plannotatora. Póki co nie wiem więcej, debuguje to. Może natrafiłeś już na ten błąd? Poniżej opis issue.)

I am seeing an intermittent issue in a local fork where the Electron window becomes blank after some time, often around a plan-review flow with active custom extension UI widgets.

Important context: the extensions involved are custom. I am mainly trying to understand whether this points to a known failure mode in extension UI/status updates, runtime-host lifecycle, Plannotator/plan-review integration, or Electron renderer recovery.

When the issue happens:

• Electron shows only the dark BrowserWindow background and macOS traffic lights.
• The Vite web app at http://127.0.0.1:5173/ still works in a normal browser.
• Logs contain many repeated extension status/widget updates.
• I also saw:
  MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process].

CDP observations while the window was blank:

• /json/list still showed a page target.
• Connecting to the page target worked, but Runtime.enable timed out.
• Browser-level CDP showed browser/GPU/network processes, but no responsive renderer process.
• Sending Page.reload via CDP restored the GUI without restarting Electron.
  So the immediate symptom seems to be a gone/hung Electron renderer rather than Vite failing.

Steps to reproduce

In my local fork this tends to happen after:

1. Running bun run dev.
2. Using Electron with custom extension UI widgets enabled.
3. Using Plannotator / completing or accepting a plan-review flow.
4. Waiting while repeated extension status/widget updates are emitted.

I can try to build a minimal repro extension if that would be useful.

Agent implementation prompt

Investigate whether repeated extension UI/status/widget updates or runtime-host reinitialization can cause the Electron renderer to hang/go blank. Inspect listener registration and lifecycle around extension binding refresh, runtime-host startup/shutdown, and Electron renderer recovery. Add diagnostics for render-process-gone, unresponsive, did-fail-load, renderer console errors, and duplicate listener registration. If reproducible, implement the smallest fix to make extension UI updates idempotent/throttled and prevent renderer hangs or unrecovered blank windows.

App version or commit

0.1.66-dev

[marcinkardas]

Hmm, wydaje mi się, że któraś z tych poprawek przyniosła efekt, bo GUI działa mi stabilniej. Godzina późna, to i wiadomość przeklejam od agenta 😶 - może dzięki temu łatwiej będzie zrozumieć ten problem.

1. Naprawiony potencjalny leak listenerów runtime-hosta

W desktop/runtime-host/host-connections.ts był singleton trzymający stan hostów przez Symbol.for('howcode.runtimeHostBrokerState'), ale flagi:

registeredHostShutdownHandlers
runtimeHostsShuttingDown

były zwykłymi zmiennymi modułu. Jeśli moduł był reimportowany / reloadowany w runtime-host context, stan hostów zostawał singletonem, ale guard listenerów resetował się. To mogło powodować dokładanie kolejnych:

process.once('exit', ...)
process.once('SIGTERM', ...)
process.once('SIGINT', ...)

i pasuje do warningu:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process].
Poprawka: te flagi zostały przeniesione do globalnego singleton state, razem z hostami/listenerami. Dzięki temu reimport modułu nie powinien ponownie rejestrować shutdown handlerów.

2. Ograniczony spam logów z Pi runtime hosta

W desktop/runtime-host/client-bridge.ts stdout/stderr z child runtime hostów były przepisywane bezpośrednio do procesu głównego:
[pi-host:service] ...
Przy widgetach/statusach extensionów pojawiały się setki/tysiące powtórzeń typu:

[workflow-status] active
[agent-fallback] active
[rpiv-todo-fork] active

Dodałem prosty deduper dla identycznych linii w krótkim oknie czasowym. Pierwsza linia nadal jest logowana, a powtórki są zwijane do np.:
[pi-host:service] [repeated 100x] [workflow-status] active
To nie zmienia logiki extensions, tylko zmniejsza presję na main process/log stream i ułatwia czytanie logów.

3. Dodana dev-only diagnostyka Electron BrowserWindow

Dodałem nowy helper src/electron/main/app/window-diagnostics.ts, podpinany w create-main-window.ts.
W dev mode loguje teraz:

webContents.on('console-message')
webContents.on('did-fail-load')
webContents.on('render-process-gone')
mainWindow.on('unresponsive')
mainWindow.on('responsive')

To ma pomóc odróżnić:

• Vite load failure,
• React/runtime error w rendererze,
• renderer process gone,
• renderer unresponsive,
• pusty #root.

4. Dev-only watchdog dla pustego root

Po did-finish-load / did-stop-loading Electron main sprawdza przez executeJavaScript, czy #root istnieje i ma dzieci. Jeśli root jest pusty, loguje stan dokumentu i robi reload z cooldownem.
To jest defensywne odzyskiwanie GUI w dev mode. Nie działa w packaged buildzie.

Gdy okno było puste, Vite nadal działał w przeglądarce. Electron CDP /json/list widział page target, ale page target nie odpowiadał na Runtime.enable. Browser-level CDP pokazywał procesy browser, GPU, network, ale nie responsywny renderer. Page.reload przez CDP przywrócił GUI i po reloadzie #root miał normalną zawartość.
Czyli objaw wyglądał jak Electron renderer gone/hung, nie jak zwykły błąd web dev servera.

[marcinkardas]

O, napisałem i Electron się zamknął całkiem przy pracy subagenta. :DDDDD

[electron-window] watchdog reloading renderer: render-process-gone { exitCode: 5, reason: 'crashed' }