mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-13 11:13:43 +08:00
3ac73623ee
mate_memory_recall.filename is VARCHAR(256), but the snippet-level recall tracker assembles the key as `path + '#' + H2-heading-slug`. When the LLM writes an over-long daily-note heading (the summarize prompt placed no length cap on the `##` title), the CJK-preserving slug pushes the filename past the column, and writes fail with Data too long / string too long. Three layers of defence, root cause + hard caps: 1. prompt (source) — summarize-system.txt now asks for short (≤30 chars) `##` titles; details go in the body, not the heading. 2. slug cap (close to source) — MemoryRecallTracker.sanitizeSectionKey caps the slug at MAX_SECTION_SLUG=200, leaving path+'#' well under 256. 3. write-side cap (catches every path) — MemoryRecallService.recordRecall truncates filename to MAX_FILENAME_LENGTH=255 at the entry point, so the select/insert/update branches share one value and the dup-key concurrency fallback still matches. Covers trackActiveRetrieval too, which bypasses sanitizeSectionKey. Tests: MemoryRecallFilenameTruncationTest covers both caps (over-long CJK heading, normal heading untouched, ascii slug, date prefix survives) plus an end-to-end assertion that the stored value fits VARCHAR(256). Existing memory-suite unit tests still green. |
||
|---|---|---|
| .. | ||
| src | ||
| Dockerfile | ||
| pom.xml | ||
| settings.xml | ||