# Opening a long thread blocks the database writer for 7–10 s · Issue \#21840 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/21840)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: backlog

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/21840)

---

**Version:** 0.1.0, Linux server, `statev2.sqlite` ≈ 10 GB.

**What happens:** opening a thread calls `http.orchestration.loadThreadSnapshotWindow` → `environment.orchestration.threadBoundedSnapshot`. Its whole duration is one `sqlite` span: the `WITH eligible AS NOT MATERIALIZED (...)` turn-items query in `readCanonicalProjection`. It runs inside `sql.transaction` with `db.connection: writer`. Seven consecutive opens measured 8.5 s median, 9.6 s max. A warm repeat of the same thread took 50 ms.

**Why it matters:** because the read holds the writer, every write waits behind it: creating a thread, dispatching a message, event-sink writes. From the client this looks like the app freezing when you switch threads or start a new one.

**Suggestion:** run snapshot reads on a reader connection outside the write transaction (WAL already allows concurrent readers). Separately, consider an index-only path for the window boundary so a cold open doesn't scan every turn item of the thread.

**Repro data:** span tree and timings from `server.trace.ndjson` are available on request. They contain no thread content.