Desktop broadcasts flood stderr while the main Renderer frame is unavailable

[me2seeks]

What happened

While the Desktop main Renderer is being replaced after a reload, navigation, or renderer-process loss, main-process broadcasts can repeatedly print:

Error sending from webFrameMain: Error: Render frame was disposed before WebFrameMain could be accessed
    at WebFrameMain.send (node:electron/js2c/browser_init:2:107951)
    at WebContents.send (node:electron/js2c/browser_init:2:93999)

Session and transcript activity can turn the short unavailable-frame interval into a large stderr flood. The app remains alive because Electron logs the failure internally, but the useful main-process log is obscured.

safeSendToRenderer() currently treats a non-destroyed WebContents as sendable:

for (const contents of recipients) {
  if (!contents.isDestroyed()) contents.send(channel, ...args);
}

That predicate is insufficient: after render-process-gone, the same WebContents reports isDestroyed() === false while its main frame can already be disposed.

Expected behavior: broadcasts should not attempt delivery to a renderer generation that has no live main frame, and renderer recovery should not flood stderr. Events that require resynchronization should still be restored by the existing recovery path once the new renderer is ready.

How to reproduce

Product trigger (timing-dependent):

1. Run Desktop from source with an active Session so Runtime Host/session events continue to be published.
2. Reload the main Renderer or trigger renderer-process recovery while events are being published.
3. Observe repeated Error sending from webFrameMain entries in the main-process output.

Deterministic Electron 43.4.1 verification:

1. Create a hidden BrowserWindow and load a page.
2. Continuously call window.webContents.send(...).
3. Call window.webContents.forcefullyCrashRenderer(), await render-process-gone, and keep sending until a replacement page has loaded.
4. The exact error above is printed repeatedly even though window.webContents.isDestroyed() is false.

The deterministic run made 9,989 send attempts and reproduced the error flood. Wrapping each webContents.send() call in application-side try/catch caught zero errors: Electron logs these failures internally, so a catch-only change does not address this reproduction.

Environment

• Maka commit: a9b4f21afb17e0ef310d076382e69ddda3a441d7
• Electron: 43.4.1
• Original observation: Windows source checkout, Desktop, npm run dev
• Deterministic verification: Linux x86_64 (7.0.0-30-generic), Desktop under Xvfb
• Node.js: v26.3.0

Logs, screenshots, or additional context

Relevant current-main boundary: apps/desktop/src/main/main-window.ts:133-138.

Known callers include Session/local-session and browser-state broadcasts. The recovery path observes render-process-gone and may reload the same main BrowserWindow, so WebContents lifetime is not the same as renderer-frame/process lifetime.

This issue is limited to broadcast behavior during the unavailable renderer interval. The cause of any particular renderer crash/reload is separate.

[Dante-dan]

I can take this. The current evidence shows that WebContents.isDestroyed() is not a sufficient renderer-generation liveness check, and application-side try/catch does not intercept Electron's internal send failure.

My plan is to trace the existing render-process-gone / replacement-load lifecycle, introduce the smallest generation-aware sendability guard at the shared broadcast boundary, and preserve the existing resynchronization path for state that must be restored after recovery. I will add a deterministic regression with a non-destroyed WebContents whose renderer frame is unavailable, verify that broadcasts are suppressed only during that interval, and run the focused Desktop tests plus the applicable lint, format, typecheck, and build checks.

AI-assisted analysis by Codex on behalf of @Dante-dan.

[Dante-dan]

take

[SummerC0zyR0ck]

Hi @Dante-dan — I saw your claim here on Sep 10 and your plan for a generation-aware sendability guard at the shared broadcast boundary. I don't see a linked PR or an assignment yet, so I wanted to check before touching anything that might duplicate your work.

Are you still planning to pick this up? If you've moved on, I'd be glad to take it. If you're still on it, no problem at all — I'll leave it to you.

Thanks!

[Dante-dan]

take

[Dante-dan]

Yes, I’m continuing with this. The assignment is now confirmed, and I’m working on the shared broadcast guard while preserving renderer recovery and resynchronization. Thanks for checking before starting overlapping work. @SummerC0zyR0ck