Opening a thread (thread.visit) waits behind the single SQLite writer and shows "Some requests are slow" (34 s) #30301

What happens

Opening a thread sends orchestration.dispatchCommand with thread.visit. That command goes through serverRuntimeStartup.enqueueCommand and waits for the single SQLite writer like any agent write. When one write holds the writer, clicking a thread shows the "Some requests are slow" toast (orchestration.dispatchCommand, waiting longer than 15 s). Nothing the user is waiting on depends on that write. The thread content loads through subscribeThread on the reader path.

Evidence (Linux, Ubuntu 24.04, 15 GB RAM, desktop 0.1.6, statev2.sqlite 5.2 GB, about 15 agent sessions running)

• ws.rpc.orchestration.dispatchCommand thread.visit took 33,920 ms. All of it was spent in serverRuntimeStartup.enqueueCommand / ThreadMessageIntake.dispatchCommand. A second thread.visit 35 s later took 6,274 ms.
• The writer was held by one orchestrationV2.EventSink.write with event_count: 1 (a claudeAgent native provider thread) for 38,680 ms. Its sql.transaction had db.lock_wait_ms: 0.019 and its commit event fired at 38,671 ms. About 20 other writers recorded db.lock_owner_at_start.span_id pointing at it, with lock waits of 5–38 s.
• That transaction has no child spans, because the body runs under withTracerEnabled(false). The trace shows the lock was held for 38 s but not what it was doing.
• Over 83 dispatches in the retained traces, p50 was 13 ms and p90 296 ms. Only the visits that landed behind a long writer were slow.
• The machine was under memory pressure: 7–8 GB of swap in use, /proc/pressure/io some avg60 about 14%. That makes each synchronous write slower, but the queueing comes from the design.

Expected

• thread.visit (and thread.mark-unread) do not block the caller. Fire and forget, or coalesce them in memory and flush later, so marking a thread as seen never waits behind agent writes.
• Bookkeeping commands like these do not count toward the "Some requests are slow" toast.
• EventSink.write keeps at least coarse child spans (normalize, append, project, outbox) when tracing is off, so a long writer-lock hold can be traced to a cause.

Related

• SQLite writes run on the server's event loop, so one slow transaction disconnects every client #30065 (writes run on the event loop)
• statev2.sqlite grows without bound (33 GB in 7 weeks): retention/compaction for orchestration events and turn items #28903 (DB growth)
• [Bug]: Server still writes ~125-155x its event data on 0.1.3 nightly (one commit per event); thread.visited still stores the full thread snapshot #24003 (thread.visited stores the full thread snapshot)
• [Bug]: Preview tabs from other threads stay alive as hidden, unthrottled webviews until restart (13 tabs, ~2.7 GB) #15579 (preview renderers left alive add to memory pressure)