Opening a long thread still takes 9–12 s on main, and each older page 3–4 s (follow-up to #24895)

Ouverte
  • Quelque chose ne va pas ?
#36,128 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@juliusmarminge y travaille déjà.

Depuis le 13/11/2026.

  • #36141 par @juliusmarminge — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
28/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
node.js, sqlite, typescript
Domaine
backend, databases, performance

Piste de recherche

Start by reading getThreadSnapshotWindow and getThreadHistoryPage in apps/server/src/orchestration-v2/ProjectionStore.ts and the query plan behind each; the #29468 comment links the covering-index approach the local build uses. Check the open pull request #36141 before touching anything, since it may already cover this work. Reproducing needs the 49 GB statev2.sqlite clone read through the real reader worker, so confirm you can get a comparable dataset first. Done looks like thread-open and older-page timings on main approaching the local-build numbers, with a query plan showing payloads are no longer decoded for run and attempt metadata.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

#24895 and #20427 were closed on November 11. On main at a044f0c0b3, opening our two coordinator threads and paging back still takes:

Read Thread A / B on main Our local build
Thread open: getThreadSnapshotWindow 11.0–11.6 / 9.1–9.8 s 3.7–4.9 s
Each older page: getThreadHistoryPage 3.0–4.2 / 2.9–3.6 s 1.0–2.1 s

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 62,950 turn items, thread B 6,886 runs and 59,668. Our local build was measured on the same clone earlier.

Where the time goes on thread A, second pass:

  • Thread open, 10.8 s:

    • the recursive retained-node read, 3.2 s;
    • checkpoints, 2.3 s;
    • provider turns, attempts and runs, 1.0–1.1 s each;
    • subagents and context transfers, 0.9 s each.

    The live-or-recent reads (status IN (...) OR ...) still take about a second each on a thread with 7,000 runs.

  • Each older page, 3.2 s: all runs, 1.1 s, and all attempts, 1.1 s, are read to render one page. A count of the earlier items takes another 0.4 s.

Our build takes a page's run and attempt metadata from covering indexes instead of decoding every payload. The #29468 comment links the code. Every thread switch to a long thread pays the open cost, and every scroll back pays the page cost.

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

Langage dominant
TypeScript
Étoiles
24.8k
Forks
6.4k
Merge moyen
59 min
PR mergées (30 j)
418

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de pingdotgg/t3code

Toutes les issues de pingdotgg/t3code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.