fix(desktop): persist renderer crashes to desktop.log + ban inline render() (React #310 class) - #83535
Merged
Merged
Conversation
…nder() isolation class Three-part class closure for the React #310 / lost-renderer-crash family (#79428, follow-up to #80560 / #82763): 1. Diagnosability (#79428 defect B): error-boundary catches now persist to desktop.log with their component stack via a new fire-and-forget hermes:logs:renderer-error IPC (synchronous flush — the window may be dying). Every renderer-content window (main, secondary session, instance, HUD, quick entry, pet overlay) gets the error-level console capture that previously only the main window had, labeled per window. 'Open logs' on the crash dialog now reveals a file that actually contains the crash. 2. Recurrence guard: eslint no-restricted-syntax rule banning inline render() calls in JSX — the mechanism behind #80560. The rule immediately caught two live sites #82763's audit missed (floating panes, narrow-overlay reveal), both hosting plugin panes. 3. Fix those two missed sites with the same ContribRender mount. extracted console-capture/report formatting to electron/renderer-log.ts with unit tests; renderer console lines now carry the window label.
Contributor
૮ >ﻌ< ა ci reviewran on a129349 — fix(desktop): persist renderer crashes to desktop.log + fini
|
teknium1
added a commit
that referenced
this pull request
Aug 11, 2026
Reconcile the salvaged #81533 lifecycle helper with the renderer-log console pipeline that landed in #83535 (the two PRs raced): - window-renderer-lifecycle.ts no longer handles console-message — renderer-log.ts is the single owner (per-window labels, boundary reports). One owner means no double-logged errors on windows wearing both, and OAuth/portal windows (lifecycle-wired for process events) cannot spill third-party page console output into desktop.log. - wake indicator window gets attachRendererConsoleCapture, keeping the console coverage it previously got from the helper. - HUD window (added after the PR branched) gets log-only lifecycle coverage — it was the one renderer window the PR couldn't have known about. - Tests updated: lifecycle helper asserts it attaches NO console-message listener; parser tests live in renderer-log.test.ts.
blut-agent
pushed a commit
to blut-agent/hermes-agent-fork
that referenced
this pull request
Aug 11, 2026
Reconcile the salvaged NousResearch#81533 lifecycle helper with the renderer-log console pipeline that landed in NousResearch#83535 (the two PRs raced): - window-renderer-lifecycle.ts no longer handles console-message — renderer-log.ts is the single owner (per-window labels, boundary reports). One owner means no double-logged errors on windows wearing both, and OAuth/portal windows (lifecycle-wired for process events) cannot spill third-party page console output into desktop.log. - wake indicator window gets attachRendererConsoleCapture, keeping the console coverage it previously got from the helper. - HUD window (added after the PR branched) gets log-only lifecycle coverage — it was the one renderer window the PR couldn't have known about. - Tests updated: lifecycle helper asserts it attaches NO console-message listener; parser tests live in renderer-log.test.ts.
prmartinow
pushed a commit
to prmartinow/hermes-agent
that referenced
this pull request
Aug 26, 2026
Reconcile the salvaged NousResearch#81533 lifecycle helper with the renderer-log console pipeline that landed in NousResearch#83535 (the two PRs raced): - window-renderer-lifecycle.ts no longer handles console-message — renderer-log.ts is the single owner (per-window labels, boundary reports). One owner means no double-logged errors on windows wearing both, and OAuth/portal windows (lifecycle-wired for process events) cannot spill third-party page console output into desktop.log. - wake indicator window gets attachRendererConsoleCapture, keeping the console coverage it previously got from the helper. - HUD window (added after the PR branched) gets log-only lifecycle coverage — it was the one renderer window the PR couldn't have known about. - Tests updated: lifecycle helper asserts it attaches NO console-message listener; parser tests live in renderer-log.test.ts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes out the React #310 / lost-renderer-crash class (follow-up to #82763): renderer error-boundary crashes now survive to
desktop.logwith their component stack, every renderer window gets error capture (not just the main one), a lint rule prevents the #310 bug shape from ever coming back — and that rule immediately caught two live inlinerender()sites #82763's audit missed.Fixes #79428.
Changes
Three layers, one class:
hermes:logs:renderer-errorIPC — the error boundary posts every catch (window label, boundary label, message, component stack) to the main process, which persists it via the desktop.log pipeline with a synchronous flush (a crashing window may be gone before the debounced timer fires). Error-level console capture, previously wired only on the main window, now attaches to all six renderer-content windows (main, secondary session, instance, HUD, quick entry, pet overlay), labeled per window. "Open logs" on the crash dialog now reveals a file that actually contains the crash.no-restricted-syntaxrule banning inlinerender()calls in JSX (the Plugin SDK crashes with React #310 when any desktop plugin is loaded on Windows (v0.20.0 / v2026.8.3) #80560 mechanism — a callback's hooks become the host's, so plugin load/replace changes the host hook count → Merge local Hermes improvements: UTF-8 hardening, context compaction,… #310).floating-panes.tsxandnarrow-overlays.tsx— both host plugin panes and both still calledrender?.()inline. Converted to theContribRendermount from fix(desktop): isolate runtime plugin render hooks #82763.Console-capture/formatting logic extracted to
electron/renderer-log.ts(main.ts previously inlined it) with unit tests; renderer console lines now carry the window label.OAuth/portal windows intentionally do NOT get the capture — third-party pages can log tokens.
Validation
vitestrenderer-log + error-boundary + slot + pane-shellnpm run typecheck(renderer + electron + e2e)eslint src/ electron/ --quietInfographic