Repository navigation
[Bug]: Thread listing builds metadata for every thread before paginating (25 s for a one-row list on a 27 GB DB) #36416
Description
Follow-up to #23000, which was closed as not planned.
On a 27 GB statev2.sqlite (+700 MB WAL), 0.1.10-nightly.20261113.4643 on Linux, the thread list still builds metadata for every thread before pagination is applied:
- a one-row thread listing took 25.1 s
- a shell metadata SELECT took 37.0 s
- reads were sub-second right after a restart and regressed to this under sustained subagent load
- writer max in the same window was 5.8 s, so this is separate from Opening a thread (thread.visit) waits behind the single SQLite writer and shows "Some requests are slow" (34 s) #30301
Applying filters and the page limit before building thread shells, and not recounting full histories for list metadata, should make list cost independent of total history size.
Related: #30875 (subagent finalize reads), #36240 and #35184 (shell snapshot cost).
Activity