A send or queued start to a long thread still reads 6–15 s of its history on main (follow-up to #29468)
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 12/100
- Tipo de issue
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- nodejs, sqlite, typescript
- Área
- backend, databases, performance
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
#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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 24.8k
- Forks
- 6.4k
- Merge medio
- 59 min
- PR fusionados (30 d)
- 418
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de pingdotgg/t3code
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
via-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
[Bug]: MCP App inline frames never go below 80px, so compact apps get blank space under themAbierto
Dificultad 2/5 Medio día Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Question card options show LaTeX as raw source, though the question text renders itPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
[Bug]: Settings inheritance popover shows raw slugs for branch naming, default permissions and response streamingPosiblemente ocupada @juliusmarminge la tomó hace 1 día. Abiertovouch:denounced
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
Todos los issues de pingdotgg/t3code
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
nikoheikkila/nikoheikkila.fi#1131 ·
Los mantenedores suelen responder en 1 día
-
Resources: Update work of urumqiPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
railmapgen/rmp-gallery#4176 ·
Los mantenedores suelen responder en 2 días
-
GraphQL custom headers duplicate differently cased default headersPosiblemente ocupada @yxr-2025 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
elie222/rakazo#4625 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
[New Project]: PacaAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
github/forgoodfirstissue#574 ·