anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #6682] fix: clear FileTime cache when sessions are deleted #12042

New Issue
Closed
opened 2026-02-16 18:16:58 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:16:58 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/6682

State: closed
Merged: No

Clears per-session file read timestamps when sessions are deleted, preventing memory accumulation during long-running sessions.

This is fairly low impact, but non-zero. The leak only occurs within a single opencode process lifetime and is cleared on exit via Instance.disposeAll().

Quantified growth rates:

  • Daily restarts (typical): <1 MB peak, reset on exit
  • 8-hour extended session: 1-5 MB peak
  • Week-long session without restart: 20-50 MB peak (unlikely usage pattern)
  • 128 MB threshold: Would require ~2,150 complex tasks (each spawning 5 subtasks reading ~30 files) in a single session - approximately one task every 2 minutes for 72 hours straight

The leak scales with # of sessions × # of unique files read, at ~160 bytes per file entry. Subtasks are the primary driver since each creates a new sessionID, so sub-task heavy users/agents are likely to see this happen more.

note: this was a bit of an exploration to see what memory leaks existed and could be tested for. I was only looking for leaks that could genuinely accumulate >= 128MB of RAM over typical-to-heavy usage, not a few KB a day. I've seen things get slow across long-running / multi-day processes and went looking for potential fixes.

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/6682 **State:** closed **Merged:** No --- Clears per-session file read timestamps when sessions are deleted, preventing memory accumulation during long-running sessions. This is fairly low impact, but non-zero. The leak only occurs within a single opencode process lifetime and is cleared on exit via `Instance.disposeAll()`. #### Quantified growth rates: - **Daily restarts** (typical): <1 MB peak, reset on exit - **8-hour extended session**: 1-5 MB peak - **Week-long session without restart**: 20-50 MB peak (unlikely usage pattern) - **128 MB threshold**: Would require ~2,150 complex tasks (each spawning 5 subtasks reading ~30 files) in a single session - approximately one task every 2 minutes for 72 hours straight The leak scales with `# of sessions × # of unique files read`, at ~160 bytes per file entry. Subtasks are the primary driver since each creates a new sessionID, so sub-task heavy users/agents are likely to see this happen more. note: _this was a bit of an exploration to see what memory leaks existed and could be tested for. I was only looking for leaks that could genuinely accumulate >= 128MB of RAM over typical-to-heavy usage, not a few KB a day. I've seen things get slow across long-running / multi-day processes and went looking for potential fixes._
yindo added the pull-request label 2026-02-16 18:16:58 -05:00
yindo closed this issue 2026-02-16 18:16:58 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#12042
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?