STUPID-2026-0080

Aider's unified-diff coder silently drops the partial-application warning when one hunk succeeds and another fails

4.2medium
August 15, 2026
  1. Instruction given

    None specific to this bug — the defect lives in Aider's unified-diff application logic itself and can trigger during any task where the model proposes multiple hunks in one diff and at least one hunk fails to apply while another succeeds.

  2. Expected behavior

    When `UnifiedDiffCoder.apply_edits` writes some hunks to disk successfully and rejects others, Aider should tell the user that a partial edit was applied, so they know the file on disk no longer matches either the original or the model's full intended diff.

  3. Actual behavior

    In `aider/coders/udiff_coder.py`, the function collects failed hunks into a list, joins that list into a single string for the error message, and then checks the string's length to decide whether to show the partial-application notice. After the `join`, `errors` is a string, so `len(errors)` measures characters in the error text rather than the number of failed hunks, and the length check for triggering the notice evaluates against the wrong quantity. The practical effect: when one hunk succeeds and another fails, the successful hunk is still written to disk, but the user is not reliably told that only part of the diff was applied.

  4. Damage

    Filed as a code-level defect by a reader of the source (yifanxiong272), with the exact file, function, and faulty length comparison identified, and a fix suggested (track the failed-hunk count before the `join` rather than measuring the joined string). No production incident or data loss was reported alongside it. The risk it documents is a user believing their edit either fully applied or fully failed when in fact a partial write landed on disk with no warning — the same silent-partial-success shape as Aider's already-flagged edit-format auto-selection (#5486) and headless exit-code (#5552) issues, this time in the unified-diff apply path. Open and unfixed as of this incident's publication.

An Aider user (yifanxiong272) reported that `UnifiedDiffCoder.apply_edits`, the function that writes a model's proposed unified-diff hunks to disk, loses its own partial-application warning under a specific condition: when a diff contains multiple hunks and at least one applies successfully while another fails. The function collects the failed hunks into a list, then joins that list into a single error-message string before checking its length to decide whether to surface the "some hunks applied, some didn't" notice to the user. Because the check runs on the string *after* the join, `len(errors)` counts characters in the assembled error text rather than the number of failed hunks — the wrong number entirely — so the length comparison that gates the warning evaluates incorrectly. The successful hunk is still written to the file regardless; what's missing is the notice telling the user that happened. The reporter pinpointed the exact file and pointed to the reversed order (measure the failed-hunk count, then join, rather than join, then measure) as the fix. No maintainer response or fix had landed as of this write-up. It's the third distinct silent-partial-success code path reported in Aider within the same week, alongside separate issues in edit-format auto-selection and headless-mode exit-code handling — different functions, same shape: work is partially or fully lost or altered with no signal reaching the user.

Classification

Agent
Aider
Failure mode
Logic Error
Root cause
Logic Error
Domain
Backend

Related incidents

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.