🤖 perf: project giant payloads in the status read of partial.json
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Refactor
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
- Domain
- performance
Research direction
Start with HistoryService.readPartial and AgentStatusService.buildTrailingTranscript, then inspect the projectStatusHistoryRow projection from #4790. Apply that projection only to the partial read used for the status transcript, preserving its non-repairing fallback. Done means large tool inputs, outputs, and file URLs are omitted while the formatted transcript remains identical.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- TypeScript
- Stars
- 2k
- Forks
- 139
- Avg merge
- 6h 58m
- Merged PRs (30d)
- 774
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from coder/xum
-
🤖 tests: localStorage budget worst-case test runs near the 5 s timeout and flakes in the merge queueOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
backlog
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
backlog
Difficulty 5/5 Over a week Newbie friendliness 38/100
Maintainers usually reply within 1 day
-
backlog
Difficulty 5/5 Over a week Newbie friendliness 20/100
Maintainers usually reply within 1 day
Similar issues
-
refactor
Difficulty 2/5 Half a day Newbie friendliness 84/100
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
OHDSI/Data2Evidence#3450 ·
Maintainers usually reply within 2 days
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
redhat-developer/rhdh-plugin-export-overlays#4011 · 1 comment ·
Maintainers usually reply within 1 day
-
automation missing-model model-sync provider:ofox
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
anomalyco/models.dev#8421 ·
Maintainers usually reply within 1 day
-
SlackAdapter and TelegramAdapter are not assignable to Adapter under exactOptionalPropertyTypesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day