[desktop] Startup blocked up to 5 min by models.dev fetch under global Flock when network silently drops packets; UI never loads #47328

Description

On Windows, the desktop app repeatedly failed to open: the window stayed stuck on the loading screen and the renderer eventually crashed with fatal renderer error: TypeError: Failed to fetch. Restarting the app did not help and often made it worse.

Root cause (verified against the bundled server code and live reproduction): during startup, when the models.dev catalog cache is missing/stale, ModelsDev.populate() acquires a global file lock (Flock, at <state>/locks/<hash>.lock) and then performs a synchronous HTTPS fetch to models.dev. Flock is configured with timeoutMs: 300_000 (5 minutes) and staleMs: 60_000. On networks where outbound packets are silently dropped (mainland China without a working proxy — connections hang for the full ~21s Windows TCP SYN retransmission window per attempt), the lock-holding process stays alive and keeps its heartbeat fresh while the fetch hangs. Every other server instance then blocks inside startup waiting on the lock, for up to 5 minutes per launch. While blocked, the local HTTP server does not answer the renderer's initial requests (/session, /config, /provider, …), so the UI never renders and the renderer eventually dies with Failed to fetch.

Killing the app mid-fetch makes the next launches even worse: the lock directory is left behind (I found an orphaned lock whose meta.json pointed to a long-dead PID), and rapid relaunches pile up lock contention.

Impact: app is completely unusable behind unstable/filtered networks, with no error message indicating the real cause and no offline fallback.

Workaround (verified): set OPENCODE_DISABLE_MODELS_FETCH=1. Startup then skips the fetch/lock path entirely: all 12 project instances finished bootstrap in ~10s with zero models.dev log entries.

Suggested fixes:

1. Never gate local-server readiness / instance bootstrap on an outbound fetch — make the catalog refresh fully asynchronous and serve stale-or-empty data meanwhile.
2. Add a short timeout (e.g. 10s) and an offline fallback to the models.dev fetch.
3. Lower the Flock timeoutMs for this call site, and on lock timeout continue bootstrap instead of blocking.
4. Surface a visible "working offline / catalog unavailable" state in the UI instead of an infinite loading screen.

Plugins

Default desktop install (one local plugin file in ~/.config/opencode/plugins, unchanged since long before the issue; ruled out by bisection).

OpenCode version

OpenCode Desktop 1.18.27 (Windows x64, packaged; Electron 42.3.3 / Node 24.15.0).

Steps to reproduce

1. Use a network where HTTPS connections to models.dev hang (silent packet drop). To simulate on any machine: block/blackhole models.dev via firewall or hosts-to-unreachable-IP.
2. Delete/expire the local models.dev cache so a fetch is triggered at startup.
3. Launch the desktop app → window stays on the loading screen; renderer later crashes with TypeError: Failed to fetch.
4. While it hangs, kill the app and relaunch → the new instance waits on the leftover/fresh lock; startup can block up to the 300s Flock timeout.

Screenshot and/or share link

N/A — logs attached instead. Key excerpts below.

{"token":"ac4513ce-0810-4d1c-9fd2-ea292da4a44b","pid":18216,"hostname":"<redacted>","createdAt":"2026-09-04T11:25:25.676Z"}

Operating System

Windows 11 (10.0.26200), x64

Terminal

N/A — desktop app (Electron sidecar server)