Render process freezes/crashes when opening session with large diffs #33195

Activity

1. mouse114514

   changed the title [-]Render process freezes/crashes when opening session with large diffs (execEditLength O(n²) on huge patches)[/-] [+]Render process freezes/crashes when opening session with large diffs[/+] on Jun 21, 2026
2. github-actions

   assigned

   Hona

   on Jun 21, 2026
3. Necmttn commented on Jun 21, 2026

   

   Necmttn

   on Jun 21, 2026

   More actions

   The session viewer should probably never run an unbounded diff algorithm on open.

   I would split this into two layers:

   • session list / open path reads only metadata plus a bounded diff summary
   • full diff rendering is lazy, size-capped, and cancellable

   For the specific regression, useful tests would cover:

   • a large patch that exceeds the cap
   • invalid or garbled encoding
   • a session with many small diffs vs one pathological diff
   • renderer stays responsive and shows "diff too large to render inline"

   The important behavior is row-level degradation. One bad tool result or diff should not make the whole session unrecoverable.

   ---

   Generated with ax.
4. mouse114514 commented on Jun 21, 2026

   

   mouse114514

   on Jun 21, 2026

   Author

   More actions

   Good point — I think the confusion is that this bug is specific to the desktop/GUI version (Electron), not the terminal TUI version. We tested the TUI and confirmed it doesn't freeze, so your understanding is correct for that target.

   The issue is in the desktop app's TimelineDiffView (packages/app/src/pages/session/timeline/message-timeline.tsx), which directly calls the O(n²) diff algorithm without any size guard — whereas the TUI apparently handles this differently. We tested with ~10k-line diffs on the latest desktop version and the renderer freezes (we have crash dumps with the stack in execEditLength → diffLines from a 33MB minidump to back this up).

   PR #33198 adds a 500-line cap with "Render Anyway" fallback, which matches the existing pattern in SessionReview. Longer term, the lazy/cancellable architecture you suggested would be the right direction.
5. mouse114514 commented on Jun 21, 2026

   

   mouse114514

   on Jun 21, 2026

   Author

   More actions

   Also, sorry — I should have made this clearer from the start: this bug is specific to the desktop/GUI (Electron) version. The TUI version does not have this unbounded diff issue. I've updated the issue description to reflect that.
6. gggbond9527 commented on Jun 22, 2026

   

   gggbond9527

   on Jun 22, 2026

   More actions

   Additional data point from OpenCode Desktop on Windows, without sharing session identifiers.

   Environment:

   • OpenCode 1.17.9
   • Windows
   • Desktop/Electron build

   Observed behavior:

   • App startup was normal and sidecar reached server ready
   • The UI then became unresponsive while opening/restoring a session
   • window.log reported renderer unresponsive
   • The renderer stack matches this issue exactly:

   at execEditLength
   at LineDiff.diffWithOptionsObj
   at diffLines
   at structuredPatch
   at createTwoFilesPatch
   at parseDiffFromFile
   at fileDiffFromContent
   at fileDiffFromPatch
   at resolveFileDiff
   

   What seems useful here is the trigger context:

   • This session was heavily focused on yudao-ui/yudao-ui-admin-vue3/src/views/system/dept/DeptImportForm.vue
   • The server log shows repeated read / git diff / edit / re-read activity around that single file
   • After restart, the app immediately resumed inspecting the same file, including checks around a specific line, BOM, and raw bytes
   • That makes it look less like a generic startup hang and more like one pathological file diff or patch payload causing the renderer-side diff computation to lock up

   What was ruled out from the logs:

   • not updater-related
   • not sidecar startup failure
   • not a network wait
   • main process was healthy; the stall point was the renderer diff path

   So this looks consistent with the existing large/pathological diff issue, but one more concrete repro clue is:

   • a session containing a problematic diff associated with DeptImportForm.vue
   • possibly involving unusual line content, encoding, BOM, or patch text shape rather than only raw file size

   I can provide the debug zip privately if maintainers want another sample set.
7. github-actions commented on Aug 22, 2026

   

   github-actionsBot

   on Aug 22, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
8. github-actions

   closed this as not plannedon Aug 22, 2026