A send or queued start to a long thread still reads 6–15 s of its history on main (follow-up to #29468)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 12/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- nodejs, sqlite, typescript
- Ambito
- backend, databases, performance
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
#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.
- Lingua principale
- TypeScript
- Stelle
- 24.8k
- Fork
- 6.4k
- Merge medio
- 59m
- PR unite (30g)
- 418
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pingdotgg/t3code
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
via-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Mezza giornata Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Question card options show LaTeX as raw source, though the question text renders itForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: Settings inheritance popover shows raw slugs for branch naming, default permissions and response streamingForse già presa @juliusmarminge l’ha presa 1 giorno fa. Apertavouch:denounced
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di pingdotgg/t3code
Issue simili
-
bug platform:mobile root-cause:found
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
openchamber/openchamber#6926 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
push-based/user-flow#356 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
Cygnux-Labs/Tracekit#827 ·
I maintainer di solito rispondono entro 1 giorno
-
www build: a refused import shows only "ENOENT scandir <outDir>", never the build-audience errorApertakind:defect
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 91/100
I maintainer di solito rispondono entro 1 giorno
-
type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
nightgauge/nightgauge#3266 ·
I maintainer di solito rispondono entro 1 giorno