Repository navigation
Conversation
The standard diff pattern matched "=======\n" and ">>>>>>> REPLACE" anywhere, so a SEARCH section containing a banner comment such as "# =========" was cut at that comment and the block silently failed to apply, and a comment containing ">>>>>>> REPLACE" ended the replacement early. The delimiter validation already reads markers as whole lines (allowing trailing whitespace and CRLF), but extraction still needed LF right after each marker, so such responses were rejected as unmatched. Extract standard blocks from the same whole-line markers the validation uses. Custom diff patterns are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The standard SEARCH/REPLACE pattern matches
=======\nand>>>>>>> REPLACEanywhere in the response, not only as whole lines. So a SEARCH section containing a banner comment (# =========================, common in generated code) is cut at that comment. The truncated SEARCH text matches nothing, andapply_diffskips the block without an error. A comment containing>>>>>>> REPLACEends the replacement early in the same way.The delimiter validation from #494 already reads markers as whole lines and allows trailing whitespace and CRLF on them. Extraction still needed an LF right after
SEARCHand=======, so a CRLF response, or one with a space after a marker, was rejected as an unmatched delimiter.Standard blocks are now extracted from the same whole-line markers the validation uses, with the same two error messages. Custom
diff_patterns and the config default are unchanged.Tests: new cases for a banner comment and marker text inside code lines, a CRLF response, and trailing whitespace on marker lines; all 4 fail on main.
test_crlf_marker_is_recognisedexpected a CRLF response to be rejected; it now expects it to parse. A differential run of the old and new extractors over 20,000 random responses without those shapes gave identical results. Full suite 900 → 904 passed, 8 skipped; the 17 errors are the integration tests that need a live LLM, same on main. Black passes.