Concurrent VS Code instances still silently crash — busy_timeout=0 still present #38849

Activity

1. github-actions

   assigned

   jlongster

   on Jul 25, 2026
2. github-actions commented on Jul 25, 2026

   

   github-actionsBot

   on Jul 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Concurrent opencode run workers can fail at startup with database is locked #33320: Concurrent opencode run workers fail at startup with "database is locked" — same SQLite busy/lock root cause
   • Concurrent opencode run instances deadlock during init (futex, no timeout) — second overlapping instance hangs forever #29395: Concurrent opencode run instances deadlock during init — same shared SQLite data dir contention
   • Multiple opencode instances in the same project share the same session via SQLite database #31307: Multiple opencode instances in the same project share the same session via SQLite database — same shared DB concern
   • opencode run: concurrent sessions crash with SQLITE_BUSY (busy_timeout=0) #21215 (closed): opencode run: concurrent sessions crash with SQLITE_BUSY (busy_timeout=0) — the direct predecessor this issue references
3. diegoT3ck commented on Aug 2, 2026

   

   diegoT3ck

   on Aug 2, 2026

   More actions

   Confirmé este mismo root cause con un disparador distinto — sin VS Code de por medio, solo terminal + opencode run.

   Escenario: un proceso opencode quedó suspendido con Ctrl+Z (estado T/Tl en ps, con hijos MCP también suspendidos) durante varios días sin cerrarse. Mientras ese proceso zombi seguía vivo, cualquier sesión nueva de opencode (TUI o opencode run "<prompt>") tenía ~1 de cada 5 intentos que se colgaba indefinidamente sin ningún error visible — el log se detenía justo después de "event connected" y nunca llegaba a crear el step de la sesión.

   Verificación:

   $ ps aux | grep opencode
   diegot3+  20118  0.7  1.1 ... Tl   jul31  24:32 opencode   # suspendido desde hace días
   diegot3+ 190680  2.9  2.3 ... Sl+  11:49   2:02 opencode   # sesión activa
   
   $ fuser ~/.local/share/opencode/opencode.db-wal
   /home/.../opencode.db-wal:  20118 190680
   

   Ambos PIDs (el zombi suspendido y el proceso activo) tenían el -wal abierto simultáneamente. Al matar el proceso zombi (kill 20118), el lock se liberó (fuser deja de reportar nada) y 8/8 pruebas posteriores con los mismos prompts que antes fallaban respondieron correctamente y de forma consistente (~7-11s cada una).

   Descarté que fuera un problema de contenido/longitud del prompt: probé variando número de palabras, presencia de ?, con/sin comillas — el fallo era puramente intermitente y correlacionaba 100% con la presencia del proceso zombi reteniendo el WAL, no con el prompt en sí.

   Esto sugiere que el fix de busy_timeout propuesto aquí (o el fork sst/opencode con busy_timeout=5000) resolvería también este caso — cualquier escenario con 2+ procesos opencode abiertos sobre el mismo opencode.db (multi-ventana VS Code, terminal + proceso suspendido, opencode run en paralelo, etc.) parece compartir la misma causa raíz.

   Entorno:

   • OpenCode version: 1.18.10
   • OS: Ubuntu (Linux 6.8.0-136-generic)
   • Instalación: Homebrew
4. github-actions commented on Oct 2, 2026

   

   github-actionsBot

   on Oct 2, 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.
5. github-actions

   closed this as not plannedon Oct 2, 2026