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

Abierto
#36,127 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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

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

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.