fix(memory-wiki): skip fenced code blocks when extracting wiki links#68852
fix(memory-wiki): skip fenced code blocks when extracting wiki links#68852altierac wants to merge 3 commits into
Conversation
Greptile SummaryThis PR fixes a false-positive lint warning in Confidence Score: 5/5Safe to merge — the change is narrow, well-tested, and introduces no behavioral change for links outside code blocks. The regex is logically correct: the backreference No files require special attention. Reviews (1): Last reviewed commit: "fix(memory-wiki): skip fenced code block..." | Re-trigger Greptile |
![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: 1091440c3a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| @@ -62,6 +62,7 @@ export type WikiPageSummary = { | |||
| const FRONTMATTER_PATTERN = /^---\n([\s\S]*?)\n---\n?/; | |||
| const OBSIDIAN_LINK_PATTERN = /\[\[([^\]|]+)(?:\|[^\]]+)?\]\]/g; | |||
| const MARKDOWN_LINK_PATTERN = /\[[^\]]+\]\(([^)]+)\)/g; | |||
| const FENCED_CODE_PATTERN = /^(`{3,})[^\n]*\n[\s\S]*?\n\1\s*$/gm; | |||
There was a problem hiding this comment.
FENCED_CODE_PATTERN requires the closing fence to be exactly the same backtick length as the opener (\1), but valid Markdown allows a closing fence with at least that many backticks. For a block like ``` ... ```` the replacement does not run, so extractWikiLinks still parses markdown-like text inside code and can reintroduce false broken-link targets (e.g. `objFoo`).
Useful? React with 👍 / 👎.
1091440 to
541e72c
Compare
extractWikiLinks() matches link patterns against the full page body including content that should not be treated as links. This causes false-positive 'Broken wikilink' lint warnings. Affected non-prose content: - Fenced code blocks: ```python stream[SessionMessage](0) ``` - HTML comments: <!-- [Old Link](removed) --> - Image syntax:  All three produce false matches against MARKDOWN_LINK_PATTERN and/or OBSIDIAN_LINK_PATTERN. Fix: strip fenced code blocks, HTML comments, and image links before running both link extraction regexes. This follows the existing pattern of stripping RELATED_BLOCK before extraction. Note: inline code spans (`[text](target)`) are intentionally NOT stripped because links like [`formatWikiLink`](sources/utils) use backticks inside valid link text. Stripping inline code globally would break these links. A context-aware inline code strip is left as future work. Adds 10 test cases covering false-positive categories, a regression guard for backtick-in-link-text, and normal link extraction.
541e72c to
8e0364b
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8e0364b14d
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| const FRONTMATTER_PATTERN = /^---\n([\s\S]*?)\n---\n?/; | ||
| const OBSIDIAN_LINK_PATTERN = /\[\[([^\]|]+)(?:\|[^\]]+)?\]\]/g; | ||
| const MARKDOWN_LINK_PATTERN = /\[[^\]]+\]\(([^)]+)\)/g; | ||
| const FENCED_CODE_PATTERN = /^(`{3,})[^\n]*\n[\s\S]*?\n\1\s*$/gm; |
There was a problem hiding this comment.
extractWikiLinks still scans links inside valid fenced code blocks that are indented (for example fences nested under list items), because FENCED_CODE_PATTERN only matches fences that start at column 0 and a closing fence with no leading indentation. In those Markdown files, snippets like obj[Foo](0) remain in searchable and produce the same false wiki-link targets this change is trying to prevent.
Useful? React with 👍 / 👎.
- FENCED_CODE_PATTERN now matches closing fences with >= opener backticks and fenced blocks indented up to 3 spaces (per CommonMark spec) - Strip order changed: HTML comments before fenced blocks to prevent a fence opener inside a comment from matching a later closing fence - 3 new edge case tests: longer closing fence, indented blocks, fence opener inside HTML comment Addresses code review feedback.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3aa01b3a94
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| .replace(HTML_COMMENT_PATTERN, "") | ||
| .replace(FENCED_CODE_PATTERN, "") |
There was a problem hiding this comment.
extractWikiLinks now removes HTML comments before fenced code blocks, so a literal <!-- inside a code fence can start a cross-line HTML_COMMENT_PATTERN match that eats real prose links until the next -->. In a page like html`…`<!--`… followed by [real](sources/good) and then -->, the real link is dropped even though it is outside code and outside any actual HTML comment. This is a regression in link discovery and can hide valid wiki dependencies.
Useful? React with 👍 / 👎.
|
Codex automated review: keeping this open. Keep this PR open. Current main still extracts wiki links after stripping only the managed Related block, so the reported fenced-code false positive is not implemented on main. The PR is relevant and narrowly scoped, but it still needs maintainer review or revision because the latest diff strips HTML comments before fenced code blocks, matching the live review concern that a literal Best possible solution: Keep the PR open as a plausible focused bug fix for What I checked:
Remaining risk / open question:
Codex Review notes: model gpt-5.5, reasoning high; reviewed against f0b327cf686e. |
Replace separate .replace() calls for fenced code blocks and HTML comments with a combined alternation pattern (FENCED_OR_COMMENT_PATTERN). The previous two-pass approach had an ordering problem: stripping HTML comments first could eat a real link when a <!-- opener appeared inside a fenced code block, and stripping fenced code first could eat a link when a backtick fence appeared inside an HTML comment. The single-pass alternation lets the regex engine pick whichever construct starts first at each position, matching CommonMark precedence. Also adds a regression test for the <!-- inside fenced code case and relaxes the mixed-content link order assertion (extraction order is an implementation detail, not a contract). Addresses ClawSweeper review feedback on strip-order concern.
|
Codex review: found issues before merge. What this changes: The PR updates memory-wiki link extraction to strip fenced code blocks, HTML comments, and image links before scanning wiki links, and adds focused Maintainer follow-up before merge: This is an open contributor implementation PR with a concrete review finding; the next action is maintainer review or an author revision on the PR branch, not a separate automated replacement branch. Review findings:
Review detailsBest possible solution: Revise the extractor so fenced-code stripping respects the opening fence length, preferably with a small line scanner or a regex that cannot close a four-backtick block on a three-backtick line. Keep the focused extractor tests and add a regression for a longer opening fence containing a shorter internal fence before the real close. Full review comments:
Overall correctness: patch is incorrect What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 8cf724a381a3. |
|
Codex review: found issues before merge. What this changes: This PR strips fenced code blocks, HTML comments, and image markdown before memory-wiki link extraction, and adds focused Maintainer follow-up before merge: This is an open contributor PR with a concrete blocking parser edge; maintainers should request or apply a small revision on the PR rather than close it or start an automated replacement lane by default. Review findings:
Review detailsBest possible solution: Revise the PR so the prefilter tracks each backtick fence opener and only closes it with a same-type fence of at least the opener length, while preserving the existing outside-code, HTML-comment, image, external-link, and anchor behavior. Add a regression where a four-backtick fence contains a shorter triple-backtick marker before markdown-like code text, then run the targeted memory-wiki markdown test. Full review comments:
Overall correctness: patch is incorrect Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 8cf724a381a3. |
|
Closing - keeping fix in fork branch for future reference. |
1 participant
Problem
extractWikiLinks()runsMARKDOWN_LINK_PATTERNagainst the full page body including fenced code blocks. Python code like:triggers false-positive
Broken wikilink target \0`lint warnings becauseSessionMessagematches thetext` markdown link regex.Fix
Strip fenced code blocks (backtick fences of 3+ chars) before running both the Obsidian and markdown link regexes. This follows the existing pattern of stripping
RELATED_BLOCKbefore extraction.One new regex constant, one additional
.replace()call, no behavioral change for links outside code blocks.Tests
Added 7 test cases for
extractWikiLinks:🤖 AI-assisted: Authored by Claude Opus 4.6 (1M context), reviewed by GPT-5.4. Edge cases found and fixed via code review pass. Human in the loop.