Files
orca/src/main
90d363afc9 fix(renderer): contain Monaco initialization failures (#21555)
* fix(renderer): add defensive error handling for Monaco editor crashes

Analyzed 34 crash reports for v1.4.205 released 2026-09-17. Identified and
added defensive fixes for React error boundary crashes in Monaco editor setup.

- Error: ReferenceError: thũs is not defined
- Location: Monaco editor initialization (editor.api2 bundle)
- Platforms: Linux, Windows, macOS
- Root cause: Undefined variable in Monaco setup or language registration
- Status: Added try-catch to prevent cascade crash

- Pattern: Cascading process deaths (network service + GPU service)
- Platforms: Primarily Windows
- Root cause: Infrastructure/concurrent process failure (not code defect)
- Status: Documented, requires Electron/Chrome infrastructure review

- Pattern: Renderer memory grows to 851MB on low-RAM Windows systems
- Root cause: Memory exhaustion on systems with <2GB free RAM
- Status: Existing memory monitoring detected; needs leak investigation

- Status: Requires minidump analysis with source maps

1. Added try-catch to Monaco editor mount callback (use-monaco-editor-mount.ts)
   - Catches errors during editor initialization
   - Logs file path and error for better diagnostics
   - Prevents crash cascade to React error boundary

2. Added try-catch to Monaco language registration (monaco-setup.ts)
   - Catches errors during Vue/Svelte/Astro/Nim language registration
   - Logs failures without crashing Monaco setup
   - Allows app to continue even if optional features fail

- Analyzed 34 crash reports across 3 categories
- Examined crash dumps, diagnostics, and memory profiles
- Reviewed Monaco setup and editor component code
- Checked git history for recent changes

- Crash breadcrumbs (memory, process state, user actions)
- Process metrics (heap, private memory, system memory)
- Component stacks (React error boundaries)
- Exit codes and system signals

- Error silently continues instead of crashing: Users get degraded experience
  instead of app crash, can still use editor in most cases
- May hide underlying issues: Errors are logged for crash reports, but won't
  be surfaced as prominently

- Type checking: pnpm tc:renderer (passed)
- Changes preserve existing error reporting through crash breadcrumbs
- Defensive coding only adds try-catch, no behavior change for success path

* fix(renderer): keep Monaco mount failures inside error boundary

* fix(renderer): isolate Monaco setup failures

* fix(renderer): contain Monaco mount failures at the editor surface

The try/catch around the onMount body did the opposite of containment: React
already routed that throw to the page boundary, so swallowing it left a
half-wired editor and hid the crash from the reporting pipeline. It also never
saw the reported failure, which is raised inside @monaco-editor/react's own
create effect before onMount runs.

Revert the hook to main and wrap the editor element in
RecoverableRenderErrorBoundary instead, so either throw degrades the file pane
only, still files a crash report, and retries by remounting on the existing
pane+path key.

* refactor(renderer): drive Monaco setup steps from one guarded table

Ten near-identical guarded calls, each repeating its own function name as a
label, become one [label, step] table run by a single loop. Same behaviour: an
optional registration that throws is logged and the rest still run.

loader.config and the editor model registry stay unguarded — they are
load-bearing, so catching there would only move the failure later.

* fix(renderer): breadcrumb swallowed Monaco setup-step failures

A guarded registration that throws was console-only, so a lost language or
behaviour guard never reached crash reports. Record a breadcrumb so the
containment stays visible in the field.

Claude-Session: ab8ff806-4870-4ea8-bbf5-bbd123b1166e

---------

Co-authored-by: m4air <m4air@Mac.localdomain>
Co-authored-by: Jinwoo-H <jinwoo0825@gmail.com>
2026-09-22 02:57:18 -04:00
..
…
2026-09-03 17:32:59 -07:00
…
…