Fix panic in project-memory loader on multibyte truncation (#46)#56
Draft
TYRMars wants to merge 1 commit into
Draft
Fix panic in project-memory loader on multibyte truncation (#46)#56TYRMars wants to merge 1 commit into
TYRMars wants to merge 1 commit into
Conversation
read_limited() and the memory-management view used String::truncate(max_bytes), which panics when max_bytes does not lie on a UTF-8 char boundary. CJK-heavy project-memory files (the repo stores zh-CN memory) routinely have a multi-byte char straddling the cap, crashing every project-bound chat turn. Add truncate_on_char_boundary() which rounds the cut point down to the nearest char boundary, and use it in both read_limited() and the management view. Fixes #46
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #46 — a reproducible panic on the main chat path.
read_limited()and the memory-management view usedString::truncate(max_bytes), which panics whenmax_bytesdoes not lie on a UTF-8 char boundary. Project-memory files are markdown that routinely contains CJK (the repo itself stores zh-CN project memory), so an oversized memory file with a multi-byte char straddling the cap crashed:read_limited()— the hot path called byload_project_memory_prompton every project-bound chat turn.project_memory.rs:158.Fix
Added
truncate_on_char_boundary(&mut String, max_bytes), which rounds the cut point down to the nearest UTF-8 char boundary (walking back frommax_byteswhile the index is not a boundary) before truncating. Both call sites now use it instead ofString::truncate.Tests
Added three unit tests:
truncate_on_char_boundary_does_not_panic_on_multibyte— caps a CJK string mid-char.truncate_on_char_boundary_is_noop_when_within_cap.read_limited_truncates_cjk_without_panicking— end-to-end through the hot path with a CJK file just over the cap.cargo test -p harness-server project_memory::andcargo clippy -p harness-server --all-targets -- -D warningsboth pass.https://claude.ai/code/session_01QMsGz6LRWe9AvY17ZW4C9B
Generated by Claude Code