A send or queued start to a long thread still reads 6–15 s of its history on main (follow-up to #29468)

Đang mở
  • Có gì không ổn?
#36,127 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
12/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
nodejs, sqlite, typescript
Lĩnh vực
backend, databases, performance

Hướng nghiên cứu

Start with the linked source points at commit a044f0c: readCommandProjection in apps/server/src/orchestration-v2/Orchestrator.ts (~line 1629) and the unfiltered read in startNextQueuedRun (~lines 2261-2272), then the t3_thread_send preflight and post-dispatch reads in apps/server/src/orchestration-v2/ThreadManagementService.ts (~840 and ~892-895). Read the #29468 comment describing the staged-read approach and reproduce against the 49 GB statev2.sqlite clone through the real ProjectionStore reader worker before changing anything. Done means a send and a queued start on the 7k-run threads no longer read full history — roughly the reported local-build numbers instead of ~11-15 s — without changing send/steer semantics.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

#29521 closed #29468, and #36100 narrowed the deferred-steer and cancel reads. On our two coordinator threads, a send and a queued start still read most of the thread's history on main at a044f0c0b3.

Setup: a block clone of our 49 GB statev2.sqlite, read through the real ProjectionStore (reader worker, node:sqlite), read-only, two passes. Thread A has 7,352 runs and thread B 6,886. Our local build was measured on the same clone earlier.

Read A / B on main Our local build
Before a send: readCommandProjection, with #35180's recent-run filter 6.7–8.6 / 6.5–7.8 s 1.8–3.1 s
Before a queued start: the same read without that filter, in startNextQueuedRun 13.9–14.6 / 11.4–15.6 s 2.3–2.7 s
t3_thread_send preflight: all runs and provider turns 2.2–2.5 / 2.2–2.5 s 4–6 ms
t3_thread_send after dispatch: all runs and all user items, to find one message's 1.9 s on A not measured

Where the time goes on thread A, second pass:

  • Before a send, 6.4 s:
    • finding the last compaction, 1.2 s;
    • provider turns, 1.2 s;
    • runs, 1.1 s;
    • root nodes, subagents, provider threads, and user and error items, 0.7 s each.
  • Before a queued start, 11.0 s:
    • user messages, 3.0 s;
    • nodes, 2.4 s;
    • runs, attempts and provider turns, 1.0–1.1 s each;
    • turn items, 0.7 s;
    • subagents, 0.6 s.

So one t3_thread_send to thread A spends about 11 s in reads, and the send read holds the thread's dispatch lock. A queued start holds the lock for its 11–15 s read before its turn start, which #35723 narrows, even begins.

Our build stages these reads; the #29468 comment describes how, with a link to the code. In short:

  • One read transaction loads the thread and its runs, and only the active subagents, sessions, provider threads, requests, scopes and transfers.
  • Messages, nodes, attempts, provider turns and items are then read by key, for the runs a send can steer, queue behind or restart.
  • The preflight reads only running runs and their running turns.

What remains there is mostly the full runs read, about 1.1 s.

Measured and written by Claude (Opus 5.5) in T3 Code; posted with the owner's approval.

Ngôn ngữ chính
TypeScript
Star
24.8k
Fork
6.4k
Merge trung bình
59 phút
Pull request đã merge (30 ngày)
418

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingdotgg/t3code

Tất cả issue của pingdotgg/t3code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.