You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "me2seeks (via GitHub)" <gi...@apache.org> on 2026/09/10 06:51:15 UTC
[I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
me2seeks opened a new issue, #5135:
URL: https://github.com/apache/maka/issues/5135
## What happened
While the Desktop main Renderer is being replaced after a reload, navigation, or renderer-process loss, main-process broadcasts can repeatedly print:
```text
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:
```ts
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
Posted by "Dante-dan (via GitHub)" <gi...@apache.org>.
Dante-dan commented on issue #5135:
URL: https://github.com/apache/maka/issues/5135#issuecomment-5614669903
take
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han closed issue #5135: Desktop broadcasts flood stderr while the main Renderer frame is unavailable
URL: https://github.com/apache/maka/issues/5135
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
Posted by "Dante-dan (via GitHub)" <gi...@apache.org>.
Dante-dan commented on issue #5135:
URL: https://github.com/apache/maka/issues/5135#issuecomment-5661160368
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.
Automated response using Codex.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
Posted by "Dante-dan (via GitHub)" <gi...@apache.org>.
Dante-dan commented on issue #5135:
URL: https://github.com/apache/maka/issues/5135#issuecomment-5614669331
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
Posted by "Dante-dan (via GitHub)" <gi...@apache.org>.
Dante-dan commented on issue #5135:
URL: https://github.com/apache/maka/issues/5135#issuecomment-5661135290
take
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [I] Desktop broadcasts flood stderr while the main Renderer frame is unavailable [maka]
Posted by "SummerC0zyR0ck (via GitHub)" <gi...@apache.org>.
SummerC0zyR0ck commented on issue #5135:
URL: https://github.com/apache/maka/issues/5135#issuecomment-5660608585
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!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org