Runtime memory logs (server/client) bounded only by 90-file count, no byte or age cap
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 76/100
Research direction
Read crates/jcode-base/src/runtime_memory_log.rs, focusing on prune_old_server_logs and prune_old_client_logs and how they sort files. Decide on a byte cap or an age cutoff, using the existing memory_log.rs retention as a reference. Done means old logs are pruned while today's file is retained and disk usage or age is bounded.
Written by the indexing model from the issue text.
Description
Summary
prune_old_server_logs/prune_old_client_logs in crates/jcode-base/src/runtime_memory_log.rs cap the runtime memory logs at 90 files each, but there is no byte or age limit. Each daily file can reach 10-15 MB on active machines (one jsonl per day in ~/.jcode/logs/memory/), so the steady state can hold roughly 1-2 GB of diagnostics that nothing else consumes.
Steps to reproduce
- Use jcode daily on a busy machine for a few weeks (server runtime memory logging is on by default,
JCODE_RUNTIME_MEMORY_LOGunset). - Check
ls ~/.jcode/logs/memory/anddu -sh ~/.jcode/logs/memory.
Expected
Log retention keeps disk usage bounded in bytes, not only in file count.
Actual
On my machine the directory reached 144 MB with 34 files, individual files up to 14 MB (server) and 10 MB (client). At the 90-file cap that pattern extrapolates to ~1 GB+. Files stay until 90 accumulate, so old diagnostics from months ago survive as long as fewer than 90 files exist.
Proposed fix
Extend the existing prune functions with a total-size cap (for example MAX_SERVER_LOG_BYTES, delete oldest files until under the cap, keep today's file) or add an age-based cutoff (for example 14 days, same as memory_log.rs uses). Both fit the current sorted-files logic, small change.
Happy to open a PR if you want.
- Dominant language
- Rust
- Stars
- 19.9k
- Forks
- 2.3k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 14
Getting set up
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 1jehuang/jcode
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
1jehuang/jcode#2076 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
bug triage: fixed-pending-release
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
1jehuang/jcode#2019 · 3 comments ·
Maintainers usually reply within 2 days
-
Add GPT-6.1 Terra to the OpenAI model libraryPossibly taken @Aafimalek claimed this 9 days ago. Opentriage: needs-decision
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
1jehuang/jcode#1997 · 2 comments ·
Maintainers usually reply within 2 days
-
bug needs-info triage: unclear
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
1jehuang/jcode#1823 · 2 comments ·
Maintainers usually reply within 2 days
Similar issues
-
🐞 bug 🧩 bevy_gantz_egui
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
nannou-org/gantz#500 ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
metasequoiaime/msime#10989 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
fritzprix/libr-agent#2612 ·
Maintainers usually reply within 1 day
-
crate: spate-core priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
NSPG13/agent-bounties#1749 ·
Maintainers usually reply within 1 day