[Bug] Desktop app renderer hangs indefinitely opening sessions with very large message history (constructMessageRows/MessageTimeline) #36379

Summary

Opening a session with a very large message history in OpenCode Desktop causes the renderer to hang indefinitely (Electron logs "renderer unresponsive"). The same session opens without issue via the CLI/TUI.

Environment

• OpenCode Desktop v1.17.18 (also reproduced on v1.17.13, prior to an auto-update)
• Windows 11
• Affected session: ~3,164 raw rows in the message table. The next-largest session anywhere else in the same local install has 647 messages — this one is roughly 5x larger than anything else, a clear outlier.

Steps to reproduce

1. Accumulate a session with several thousand messages (ours reached ~2,950 before we started investigating, now ~3,164 after compaction).
2. Open OpenCode Desktop.
3. Navigate into that session (or let it auto-restore on launch).

Expected behavior

Session opens and becomes interactive within a few seconds, same as any other session.

Actual behavior

• Renderer becomes unresponsive (Electron's renderer unresponsive event in window.log).
• Stack trace samples captured during the hang consistently point to the same call chain:

  constructMessageRows → createTimelineProjection → MessageTimeline
  

  reached via loadOlderTimeline → loadOlder → applyMessagePage → loadMessages → loadMore.
• Reproduced identically across 3 separate desktop launches in a row.
• Sometimes self-recovers after several seconds (renderer responsive logged shortly after), but in one occurrence it did not recover at all during the session.

What we ruled out

• Not a backend/server issue — opencode.log shows the server loading all projects/sessions cleanly, no errors logged during any of the hangs.
• Not fixed by /compact — running /compact on the affected session (which non-destructively hides old messages from future context, per the docs) did not stop the desktop app from hanging on reopen. The raw row count in the message table is unaffected by compaction (it actually grows slightly, since compaction itself adds messages). This suggests the desktop timeline builds rows from the full raw message history rather than a paginated/limited subset.
• The TUI opens the same session fine — likely because the TUI has a hardcoded ~100-message load limit (see [BUG] Cannot scroll to beginning of long conversations (message limit hardcoded to 100) (#6138) #6137 and feature request: pagination for messages & sessions #4918), while the desktop app appears to load the entire history at once.
• Not a database integrity issue — PRAGMA quick_check on the SQLite database returned ok. This is a pure rendering/performance issue, not data corruption.

Suggested fix

Apply the same kind of message-count cap or pagination in the desktop timeline that the TUI already has (tui.messages_limit, see #6137 / #4918), or make constructMessageRows incremental/virtualized so a large session's full history doesn't block the main thread.

Workaround

Access the affected session via the CLI/TUI (opencode -s <session-id>) instead of the desktop app until this is fixed.