[Bug] Desktop renderer freezes on startup — Solid.js signal infinite loop (v1.17.15, Windows) #35901

Bug Report

Version: 1.17.15 (Electron 42.3.3 / Chrome 148)
OS: Windows 11 (x64)
Channel: latest (auto-update from 1.17.8 → 1.17.14 → 1.17.15 on 2026-07-07)

Description

The renderer process becomes completely unresponsive within 41–90 seconds of app startup — before any user interaction. This blocks the main JS thread indefinitely, making the Electron window unresponsive.

The issue occurs on first launch after each system reboot. After closing and relaunching without rebooting, the freeze takes longer to appear (or may not appear immediately), suggesting a race condition triggered by OS-level initialization.

Not a diff-computation bug

This is different from the existing execEditLength / LineDiff freeze tracked in issues #32046, #33106, etc. The call stacks below show Solid.js reactive signal system deadlocks, not diff computation blocking.

Root Cause (from debug logs)

Two distinct but related call stacks appear in window.log — both are Solid.js reactive loop deadlocks:

Sample 1 — lookUpstream signal recursion:
at lookUpstream (main-ClUtJP2v.js) at Object.getTextValue at Object.getSectionChildren at Object.buildNodes at Object.lookUpstream [6+ levels deep, recursive] at Object.getSectionChildren at Object.buildNodes

Sample 2 — getOwnPropertyDescriptor Proxy trap loop:
at Object.getOwnPropertyDescriptor (main-ClUtJP2v.js:943:27) at Object.keys at Object.ownKeys at Object.keys at Object.keys at Object.getOwnPropertyDescriptor [repeated] at AccordionTrigger at ButtonRoot at CollapsibleTrigger at TooltipTrigger at Object.get [repeated many levels]

Manifest uptime: ~47s — freeze occurred before 1-minute mark (first sample at ~41s after startup).

Reproduction

1. Reboot Windows
2. Launch OpenCode 1.17.15
3. App appears to load normally
4. Within 41–90 seconds, renderer becomes unresponsive

Attempted fixes that did NOT resolve the issue:

• Cleared all renderer caches (Cache, GPUCache, Code Cache, DawnGraphiteCache, DawnWebGPUCache, blob_storage, Local Storage, Session Storage, Network)
• Problem persists after cache wipe — freeze occurred at ~41s vs ~87s (even faster)
• Problem also occurs on 1.17.8 and 1.17.14 — not new to 1.17.15

Affects multiple versions

Confirmed affected: 1.17.8, 1.17.14, 1.17.15 (all Windows x64).
Similar Solid.js signal loops reported on macOS arm64 in v1.17.11 (issue #34421).

Debug Logs

Full debug bundles:

• opencode-debug-20260708T112701.zip — first occurrence (~87s freeze)
• opencode-debug-20260708T113552.zip — after cache clear (~41s freeze, faster)

Both contain manifest.json, main.log, window.log with full unresponsive samples.

Suggested fix direction

The freeze is triggered during initial UI render (Accordion, Button, Collapsible components) when Solid.js reactive dependency tracking enters a circular loop:

1. Add cycle detection in lookUpstream / signal graph traversal
2. Ensure component props are stable references (avoid triggering Proxy traps on object spread)
3. Add a renderer freeze watchdog that breaks out of long synchronous computations
4. Defer non-critical UI rendering on startup