🤖 perf: project giant payloads in the status read of partial.json
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 82/100
- Tipo di issue
- Refactoring
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- performance
Direzione di ricerca
Inizia con HistoryService.readPartial e AgentStatusService.buildTrailingTranscript, quindi esamina la proiezione projectStatusHistoryRow di #4790. Applica questa proiezione solo alla lettura parziale utilizzata per la trascrizione dello stato, preservandone il fallback non riparatore. Il lavoro è completato quando gli input grandi degli strumenti, gli output e gli URL dei file vengono omessi, mentre la trascrizione formattata rimane identica.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
Every sidebar status run also reads the in-flight partial.json (HistoryService.readPartial in AgentStatusService.buildTrailingTranscript). While an agent streams a giant turn (inline attachments, multi-MB tool output), that file holds the same giant payloads. Measured with a 12.3 MiB partial.json: 39 ms (node) and 46 ms (bun) per status run, without the history lock, every 10 s for an active focused workspace.
Proposed change
Apply the #4790 status projection (projectStatusHistoryRow: tool input/output to null, file url to "") to the partial read used by the status transcript only, with the same non-repairing fallback. The formatter never reads those fields, so the transcript stays identical.
Refs #4790
Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $26.27
- Lingua principale
- TypeScript
- Stelle
- 2.1k
- Fork
- 142
- Merge medio
- 4h 59m
- PR unite (30g)
- 902
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna 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 coder/xum
-
tech-debt
Difficoltà 2/5 Mezza giornata Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
approved backlog
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
approved backlog
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
area:workflow bug ready-for-human
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
fil-donadoni/tolaria#6108 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
apache/rocketmq-dashboard#7234 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
vitest-dev/vitest#11656 ·
I maintainer di solito rispondono entro 1 giorno
-
e2e-failure ready-to-code
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
redhat-developer/rhdh-plugin-export-overlays#4460 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
ehmpathy/rhachet-roles-bhrain#655 ·
I maintainer di solito rispondono entro 1 giorno