🤖 perf: project giant payloads in the status read of partial.json
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 82/100
- Tipo de issue
- Refactorización
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- performance
Línea de trabajo
Empieza con HistoryService.readPartial y AgentStatusService.buildTrailingTranscript; después, inspecciona la proyección projectStatusHistoryRow de #4790. Aplica esa proyección únicamente a la lectura parcial utilizada para el transcripto de estado, conservando su fallback no reparador. Se considera terminado cuando se omiten las entradas grandes de las herramientas, sus salidas y las URL de archivos, mientras el transcripto formateado permanece idéntico.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- TypeScript
- Estrellas
- 2k
- Forks
- 139
- Merge medio
- 6 h 35 min
- PR fusionados (30 d)
- 819
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Sin 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 coder/xum
-
🤖 Delegated-turn delivery and peer-limit follow-ups from #5311 and #5327Posiblemente ocupada @ThomasK33 la tomó hoy. Abierto
Los mantenedores suelen responder en 1 día
-
🤖 Compaction follow-up dispatch: remaining follow-ups from #5313Posiblemente ocupada @ThomasK33 la tomó hoy. Abierto
Los mantenedores suelen responder en 1 día
-
🤖 Concurrency primitive and fileLock hazards found by the formal models (#5309, #5319 follow-ups)Posiblemente ocupada @ThomasK33 la tomó hoy. Abierto
Los mantenedores suelen responder en 1 día
-
🤖 History persistence follow-ups from the formal-verification fixes (#5312, #5316, #5318)Posiblemente ocupada @ThomasK33 la tomó hoy. Abierto
Los mantenedores suelen responder en 1 día
-
🤖 MessageQueue: prove held sends cannot wait on an orphaned compaction decision (resume without compaction metadata)Posiblemente ocupada @ThomasK33 la tomó hoy. Abierto
coder/xum#5326 · 1 comentario · 1 asignado ·
Los mantenedores suelen responder en 1 día
Issues similares
-
bug via-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
pingdotgg/t3code#14452 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
solana-foundation/program-examples#747 · 1 comentario ·
Los mantenedores suelen responder en 9 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
remotion-dev/remotion#11847 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
openwatersio/slackwater#355 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
melgarafael/DeskcommCRM#1998 · 3 comentarios ·
Los mantenedores suelen responder en 1 día