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

オープン
  • 何か問題がありますか？
#36,127 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
nodejs, sqlite, typescript
領域
backend, databases, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

#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.

主要言語
TypeScript
スター
24.8k
フォーク
6.4k
平均マージ
59分
マージ済み PR（30日）
418

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

pingdotgg/t3code のほかの issue

pingdotgg/t3code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。