chat: handle invalid URIs in extractCodeblockUrisFromText

[roblourens]

Summary

Fixes a crash in the chat renderer when an LLM response contains a literal <vscode_codeblock_uri> tag with non-URI content (e.g. backtick-fenced code blocks).

Problem

When a Copilot agent discusses VS Code's own chat annotation code, it may include a literal <vscode_codeblock_uri> XML tag in its markdown response. The regex in extractCodeblockUrisFromText matches the tag and passes the inner content to URI.parse(). When that content starts with a backtick or other illegal URI scheme character, URI.parse throws a UriError that propagates up through trackToolMetadata → appendItem → renderMarkdown → renderChatContentPart, crashing the chat list renderer.

Fix

Wrap the URI.parse(uriString) call in a try-catch that returns undefined on failure. All callers already handle undefined gracefully:

• trackToolMetadata (thinking header): Falls to the else branch → shows "Edited file" label
• chatMarkdownContentPart (code block rendering): codemapperUri stays undefined → renders as a normal code block instead of an edit pill

Added a test case for the invalid URI scenario.

Fix #309299

[Copilot]

Pull request overview

Fixes a crash in the chat renderer when <vscode_codeblock_uri>...</vscode_codeblock_uri> tags contain non-URI text (e.g. markdown code fences) by making URI extraction tolerant of parse failures.

Changes:

• Wrap URI.parse() in extractCodeblockUrisFromText with a try/catch and return undefined on parse failure.
• Add a unit test covering invalid (non-URI) content inside the codeblock URI tag.

Show a summary per file

File	Description
src/vs/workbench/contrib/chat/common/widget/annotations.ts	Prevents renderer crashes by safely handling invalid URI strings when extracting codeblock URIs.
src/vs/workbench/contrib/chat/test/common/widget/annotations.test.ts	Adds regression coverage ensuring invalid tag content returns undefined instead of throwing.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 0

[Copilot]

Pull request overview

Fixes a crash in VS Code’s chat rendering pipeline caused by invalid <vscode_codeblock_uri> tag contents (e.g. LLM-produced literals that aren’t parseable URIs), and tightens annotation detection to reduce false positives from code examples.

Changes:

• Anchor <vscode_codeblock_uri> extraction to end-of-text and guard URI.parse(...) with try/catch to avoid renderer crashes on invalid URIs.
• Update hasCodeblockUriTag / hasEditCodeblockUriTag to ignore tags that occur inside complete fenced code blocks.
• Add/extend unit tests covering invalid URI content, end-anchored matching, and fenced-code-block filtering.

Show a summary per file

File	Description
src/vs/workbench/contrib/chat/common/widget/annotations.ts	Adds end-anchored extraction + URI.parse error handling; updates tag-detection helpers to strip complete fenced blocks first.
src/vs/workbench/contrib/chat/test/common/widget/annotations.test.ts	Adds regression tests for invalid URI/tag placement and for tag detection behavior around fenced code blocks.

Copilot's findings

Comments suppressed due to low confidence (2)

src/vs/workbench/contrib/chat/common/widget/annotations.ts:273

• stripCompleteFencedCodeBlocks only matches fences that start at column 0 (^({3,}|~{3,})`). In CommonMark (and in this repo’s markdown parsing/tests), fenced code blocks can be indented (e.g. inside list items with up to 3 leading spaces), so tags inside indented fences will not be stripped and hasCodeblockUriTag/hasEditCodeblockUriTag can still return true for LLM-generated code examples. Consider allowing optional leading whitespace on both opening/closing fence lines (or reusing the existing fence-scanning logic from isInsideCodeContext).

	while ((match = /<vscode_annotation details='(.*?)'>(.*?)<\/vscode_annotation>/ms.exec(newText)) !== null) {
		const [full, details, content] = match;
		const start = match.index;
		const textBefore = newText.substring(0, start);
		const linesBefore = textBefore.split('\n').length - 1;
		const linesInside = content.split('\n').length - 1;

		const previousNewlineIdx = textBefore.lastIndexOf('\n');

src/vs/workbench/contrib/chat/test/common/widget/annotations.test.ts:379

• The new hasEditCodeblockUriTag/hasCodeblockUriTag behavior is only tested with non-indented fenced blocks. Since fenced blocks can be indented (e.g. within lists), it would be good to add a test case with leading spaces before the opening/closing fences to ensure stripCompleteFencedCodeBlocks actually ignores tags inside those code examples.

• Files reviewed: 2/2 changed files
• Comments generated: 0 new