fix(amazonq): unescape HTML entities and backslash-escaped angle brackets #2415
Conversation
…sReplace The fsReplace tool was failing with TextNotFoundError because the LLM receives HTML-escaped prompts and returns oldStr values with similar escaping. This fix adds unescaping for both HTML entities and backslash-escaped angle brackets before matching against file content. Changes: - Add unescapeHtml() function to textFormatting.ts to handle both HTML entity unescaping (< → <, > → >, etc.) and backslash-escaped angle brackets (\< → <, \> → >) - Update fsReplace.ts to unescape oldStr and newStr before normalization - Import unescapeHtml from textFormatting module for reusability
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2415 +/- ##
==========================================
+ Coverage 62.30% 62.32% +0.01%
==========================================
Files 266 266
Lines 59198 59227 +29
Branches 3793 3794 +1
==========================================
+ Hits 36886 36914 +28
Misses 22237 22237
- Partials 75 76 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| * 1. HTML escaping done by escape-html: " → ", & → &, ' → ', < → <, > → > | ||
| * 2. Backslash escaping of angle brackets that may appear in the LLM response: \< → <, \> → > | ||
| */ | ||
| export function unescapeHtml(text: string): string { |
There was a problem hiding this comment.
You can use "unescape-html": "^1.1.0" also
declare module 'unescape-html' {
function unescapeHTML(str: string): string
export = unescapeHTML
}
Check this PR: https://github.com/aws/language-servers/pull/2360/files#diff-fbaaeff7c4b028ae726c46e4eea2adec92e5fd886d26d5eee21fba8dc67ecfe8L71
|
|
||
| // Unescape HTML entities in oldStr since the prompt was HTML-escaped before being sent to LLM | ||
| const unescapedOldStr = unescapeHtml(diff.oldStr) | ||
| const unescapedNewStr = unescapeHtml(diff.newStr) |
There was a problem hiding this comment.
are we sure this will not introduce any regression? This is a risky change, what is prompting us to make this change?
There was a problem hiding this comment.
fsReplace failures because LLm is reading sanitized prompt. When users are sending code in prompt usingSend to prompt right click. we are sanitizing it with escapeHtml. When there are special characters in said code is making LLM retrun code with incorrect old str
4 participants
Problem
The fsReplace tool was failing with TextNotFoundError because the LLM receives HTML-escaped prompts and returns oldStr values with similar escaping. This fix adds unescaping for both HTML entities and backslash-escaped angle brackets before matching against file content.
Solution
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.