Deleting a session is slow/hangs, leaves ghost sessions, and can freeze the whole app #42538

Activity

1. github-actions

   assigned

   Hona

   on Aug 14, 2026
2. github-actions commented on Aug 14, 2026

   

   github-actionsBot

   on Aug 14, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Session close or delete not working/crashing #38771: Session close or delete not working/crashing — same symptom of deletion failing/crashing
   • [BUG] Subagent final part lost — SessionProcessor.cleanup races with "removing share" (1.17.18) #36670: removing share race condition (SessionProcessor.cleanup FK conflict) — same removing share log entries you observed, potentially the same root cause
   • 最新Windows 客户端 删除当前会话，顶部会话不会消失点击后会报错 #32492: Windows session delete leaves ghost sessions that error on click — same ghost-session + Windows symptoms

   If your issue is distinct (e.g., the hang/freeze angle is new), feel free to keep this open and note what differs.
3. mradwankhalil commented on Aug 18, 2026

   

   mradwankhalil

   on Aug 18, 2026

   Contributor

   More actions

   Additional Windows/Desktop evidence from OpenCode 1.18.18:

   • The freeze consistently followed deleting a session. In one incident, main.log stopped at 08:40:57.533 and renderer.log stopped at 08:41:01.113. No Electron unresponsive event/recovery dialog, Crashpad dump, or Windows AppHang/AppCrash event appeared; the sidecar continued independently.
   • A no-deletion control session survived 34+ minutes and saw ResizeObserver bursts up to 326/min, while the frozen session peaked around 147/min. ResizeObserver volume alone is therefore not sufficient.
   • The delete path is: packages/app/src/pages/session/timeline/message-timeline.tsx:865-925 calls the session DELETE endpoint, updates the client session list, evicts cached data, and dispatches tab removal. The server path reaches packages/opencode/src/session/session.ts:608-625, which cancels matching background jobs, publishes session.deleted, and removes the event aggregate. packages/core/src/event.ts:514-523 deletes the event sequence and event rows in a transaction.
   • The post-delete renderer cleanup reaches packages/app/src/context/tabs.tsx:298-349, which updates persisted tab/closed/info state. Desktop persistence ultimately reaches packages/desktop/src/main/ipc.ts:124-126, where electron-store.set() is called synchronously on the Electron main process.

   This makes a main-process persistence stall a plausible explanation for the simultaneous Desktop freeze, but I cannot yet prove which individual write blocks or how long it takes. One correction to earlier speculation: packages/app/src/context/notification.tsx handles session.idle/session.error and prunes to 500 entries/30 days; it does not directly handle session.deleted, so the notification list should not be treated as the confirmed delete trigger.

   The SQLite cleanup I performed locally preserved all 121 sessions and removed only 26 orphan events, 2 orphan event sequences, and 2 stale runtime directories; post-clean integrity checks passed. It did not delete sessions or establish the Desktop freeze root cause.

   Could this be triaged as a Windows Desktop session-delete/persistence hang, with instrumentation or a regression test around the delete-to-tab-persistence path?
4. mradwankhalil commented on Aug 19, 2026

   

   mradwankhalil

   on Aug 19, 2026

   Last edited by mradwankhalil

   Contributor

   More actions

   A second, non-delete reproduction of the same silent hang (2026-08-19, Windows 11, Desktop 1.18.18):

   • Trigger was a plain UI navigation: clicking a completed subagent inside the largest session in the DB (781 messages, 4,224 parts, approximately 14 MB of part data, still live). No session deletion involved.
   • Timeline (local UTC+3): 05:14:41 click; burst of 14 ResizeObserver errors in approximately 3 seconds; renderer.log last line 05:14:44.077; main.log silent since 05:07:55 (last updater check); sidecar (opencode.log) kept working normally until the app was killed at 05:15:14. No Electron unresponsive event, Crashpad dump, or AppHang/AppCrash.
   • This is the second incident with zero deletions (the 08:41 freeze yesterday also occurred without pruning), so the freeze is not delete-specific: rendering or navigating a heavy session is an independent trigger.
   • Same fingerprint as the delete-triggered incidents: renderer ResizeObserver burst; both main and renderer stop logging approximately 4 seconds apart; no crash artifacts; sidecar continues independently. DB health was confirmed (quick_check=ok, zero FK violations).

   This still fits the main-process persistence stall hypothesis (renderer state flood leading to synchronous electron-store.set() on the main process, ipc.ts:124-126), but the trigger is broader than deletion. Worth investigating the session virtualizer re-render path (session.tsx:1583 content to fill()) for large sessions? Happy to capture a Chromium trace on the next freeze.
5. mradwankhalil commented on Aug 19, 2026

   

   mradwankhalil

   on Aug 19, 2026

   Contributor

   More actions

   Related evidence now posted on #36670: #36670 (comment)

   Before today's Desktop freeze, one completed subagent in the audit tree had the same user-visible symptom as #36670: earlier work was persisted, but the final deliverable was missing. Its SQLite session remained present, but its last message ended with finish: tool-calls, with no final results text, clean step-finish, or exiting loop / cancel entry. Four sibling subagents completed normally.

   I did not find removing share, SessionProcessor.cleanup, or FOREIGN KEY constraint failed in today's log, so the exact #36670 deletion race is not proven here. However, the missing-final-part state was followed by navigation through the subagent tree and the same Desktop renderer/main-process hang signature. This suggests the subagent completion/cleanup failure and the Desktop freeze may be related stages of the same lifecycle problem, rather than an unrelated heavy-render case.
6. mradwankhalil commented on Oct 10, 2026

   

   mradwankhalil

   on Oct 10, 2026

   Contributor

   More actions

   The evidence now separates at least two triggers: delete-path freezes and a no-deletion heavy-session navigation freeze. The synchronous Desktop store.set() is a plausible common stall, but not proven. Could maintainers nominate an instrumentation point or regression harness for renderer-to-IPC persistence latency, and confirm whether #42538 should remain distinct from the removing-share race in #36670?
7. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
8. thdxr

   closed this as not plannedon Oct 11, 2026