release: v0.2.5815 — consolidate 5814 max_cached wiring + main's session perf+context PRs#480
Conversation
PR #208 added a CLOCK eviction cache but hardcoded its capacity to 16384, leaving .codedbrc's max_cached parsed-and-forgotten. Thread the configured value through Explorer.init and the MCP ProjectCache so the knob actually controls cache size. Default bumped from 1000 to 16384 to preserve pre-fix behavior for users without a .codedbrc. Issue-102 tests rewritten to assert the wiring end-to-end. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…hContext init callsites The cherry-pick of #460 (.codedbrc max_cached wiring) reshaped Explorer.init and BenchContext.init to take an explicit cache capacity. Update the 3 Explorer.init + 2 BenchContext.init callsites I added in the PR #471 / PR #478 tests to pass Explorer.DEFAULT_CONTENT_CACHE_CAPACITY.
Benchmark Regression ReportThresholds: 10.00% and 50,000 ns absolute delta
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85ad3b7032
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| var explorer = Explorer.init(allocator); | ||
| explorer.content_cache_limit = cfg.max_cached; | ||
| var explorer = Explorer.init(allocator, cfg.max_cached); |
There was a problem hiding this comment.
This now feeds cfg.max_cached straight from .codedbrc into Explorer.init, but the config parser only enforces > 0 and does not cap upper bounds. Since config resolution prefers $CWD/.codedbrc (Config.loadDefault), running codedb in an untrusted repo can set an extremely large max_cached, causing ContentCache.init to attempt a huge allocation and panic on OOM instead of recovering; in MCP mode the same value is propagated to per-project explorers as well. Please bound max_cached to a sane maximum before using it in allocator-sized capacities.
Useful? React with 👍 / 👎.
Benchmark Regression ReportThresholds: 10.00% and 50,000 ns absolute delta
|
1 participant
Summary
Builds a
release/v0.2.5815branch off latestmain(which already contains PRs #474–#479 from this session) and brings in the one outstanding commit fromrelease/v0.2.5814that wasn't on main: PR #460's.codedbrc max_cachedwiring (4433aec).release/v0.2.5813is fully merged into main already — nothing to bring over from it.Branch composition
main(76a3588)release/v0.2.5814cherry-pick (4433aec).codedbrc max_cachedflows intoContentCache.initcapacity (was hardcoded 16384);Explorer.initandBenchContext.initnow take an explicitcontent_cache_capacityparameter85ad3b7)Explorer.DEFAULT_CONTENT_CACHE_CAPACITYrelease/v0.2.5813has 0 commits not on main — nothing to cherry-pick.Test plan
zig build(ReleaseFast) passeszig build test— 488/489 pass (1 pre-existing failure onmain:issue-44)DEFAULT_CONTENT_CACHE_CAPACITY = 16384preserves pre-fix capacity for users without.codedbrcWhy a release PR
This is the natural cutting point for the next tagged release: it groups all the session's user-visible improvements (faster status, faster word, leaner search, new context tool, fixed find argument errors, richer context output) with the outstanding
.codedbrcwiring fix.