Skip to content

[BUG] find_hunk_position() silently applies hunk at wrong position when context doesn't match, corrupting files (apply_patch.rs:430) #145

@sysprime10001

Description

@sysprime10001

Bug: find_hunk_position() silently applies hunk at wrong position when context doesn't match, corrupting files

Location

src/cortex-engine/src/tools/handlers/apply_patch.rs, lines 390-438

Description

find_hunk_position() is supposed to find the correct position in a file to apply a diff hunk by matching context lines. When context matching fails at the suggested position, it searches ±50 lines for a match. However, if no match is found at all, the function silently falls back to suggested_start (line 430-431) instead of returning an error:

// If we can't find a match but we have the right number of lines, use suggested position
if suggested_start <= lines.len() {
    return Ok(suggested_start);
}

This means when a file has been modified and the context lines no longer match anywhere, the hunk is applied at the original line number anyway — silently inserting/removing lines at the wrong position and corrupting the file contents without any warning or error.

Steps to Reproduce

  1. Create a file test.txt with content:
alpha
beta
gamma
delta
epsilon
  1. Create a patch that modifies lines 2-3 with context:
--- a/test.txt
+++ b/test.txt
@@ -1,5 +1,5 @@
 alpha
-beta
-gamma
+BETA
+GAMMA
 delta
 epsilon
  1. Before applying the patch, modify test.txt so the context no longer matches:
COMPLETELY
DIFFERENT
CONTENT
HERE
NOW
  1. Apply the patch — find_hunk_position will fail to match context at any position within ±50 lines, but will silently fall back to suggested_start (line 0), applying the hunk at position 0 and corrupting the file.

Root Cause

Line 430: if suggested_start <= lines.len() is almost always true (since suggested_start is derived from the hunk's old_start which is typically a valid line number), so the fallback fires whenever context matching fails. The function returns Ok(suggested_start) — a success result — instead of Err(...), so the caller has no way to know the hunk was applied at an unverified position.

Expected Behavior

When no context match is found within the search range, find_hunk_position should return an error indicating the context mismatch, allowing the caller to abort or warn the user. The current behavior silently corrupts files.

Impact

  • Data loss: Files are silently modified at wrong positions when context doesn't match
  • No user feedback: The operation reports success even when the patch was misapplied
  • Difficult to diagnose: Since there's no error or warning, users won't know their file was corrupted until they notice unexpected changes

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions