fix(memory-wiki): strip fenced code blocks before wikilink extraction (fixes #97945)#97964
fix(memory-wiki): strip fenced code blocks before wikilink extraction (fixes #97945)#97964zw-xysk wants to merge 1 commit into
Conversation
…fixes openclaw#97945) Fenced code blocks and inline code spans containing [[...]] patterns (e.g. Scala generics Future[Option[User]], bash [[ "" == "y" ]]) were falsely reported as broken wikilink targets. Strip them from the searchable text before running the wikilink regex. This reopens and implements the validated fix from openclaw#70986.
|
Thanks for the context here. I swept through the related work, and this is now duplicate or superseded. Close: this PR is a redundant landing candidate because #97954 already covers the same Memory Wiki extractor fix with regression coverage and positive real CLI proof, while current main still needs exactly that bugfix. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Canonical path: Use #97954 as the landing path, then let it close #97945 when merged. So I’m closing this here and keeping the remaining discussion on #97954 and #97945. Review detailsBest possible solution: Use #97954 as the landing path, then let it close #97945 when merged. Do we have a high-confidence way to reproduce the issue? Yes. Current main still extracts links from markdown after removing only the managed related block, and lint turns unmatched extracted targets into broken-wikilink warnings; I did not run the CLI because this read-only review cannot write report/log artifacts. Is this the best way to solve the issue? No. The production change is plausible, but the better landing path is the earlier open PR with the same extractor fix, focused regression coverage, and after-fix CLI output. Security review: Security review cleared: No concrete security or supply-chain issue was found; the diff is limited to Memory Wiki markdown parsing with no workflow, dependency, lockfile, install, release, permission, or secret-handling changes. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 28347ba51c3d. |
|
Tests: 10/10 ✅. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
clawsweeper
Bot
added
rating: 🧂 unranked krab
1 participant
What Problem This Solves
Fixes #97945 (reopening #70986).
openclaw wiki lintproduces large numbers of false-positiveBroken wikilink targetwarnings from[[...]]patterns inside fenced code blocks (e.g. Scala genericsFuture[Option[User]], bash[[ "$x" == "y" ]]) and inline code spans.Changes
```...```) and inline code spans (`...`) from the searchable text before running the wikilink regex inextractWikiLinks()Evidence
Unit tests (10/10 passed):
git diff:
const RELATED_BLOCK_PATTERN = new RegExp( `${WIKI_RELATED_START_MARKER}[\\s\\S]*?${WIKI_RELATED_END_MARKER}`, "g", ); +/** Matches fenced code blocks (```...```) including the language tag. */ +const FENCED_CODE_BLOCK_PATTERN = /```[\s\S]*?```/g; +/** Matches inline code spans (`...`). */ +const INLINE_CODE_PATTERN = /`[^`]+`/g; function extractWikiLinks(markdown: string, sourceRelativePath: string): string[] { - const searchable = markdown.replace(RELATED_BLOCK_PATTERN, ""); + const searchable = markdown + .replace(RELATED_BLOCK_PATTERN, "") + .replace(FENCED_CODE_BLOCK_PATTERN, "") + .replace(INLINE_CODE_PATTERN, "");Before fix: 2,626 lint warnings including ~1,697
Broken wikilink target(from #97945)After fix: code block
[[...]]patterns no longer produce false positives.AI Assistance