A one-line ordering mistake in Aider's diff-application code means that when part of a multi-hunk edit fails, the tool can write the successful part to disk without ever telling you.
What happened
Filed as GitHub issue #5573, the report comes from a reader of Aider's own source (yifanxiong272) rather than from a crash or a support ticket. They traced UnifiedDiffCoder.apply_edits — the function that writes a model's proposed unified-diff hunks to disk — and found a length check that measures the wrong quantity.
When a diff has multiple hunks and some fail to apply while others succeed, the function is supposed to warn the user that only part of the edit landed. To decide whether to show that warning, it collects the failed hunks into a list, joins that list into a single error-message string, and then checks the string's length. After the join, errors is a string — so len(errors) counts characters in the assembled error text, not the number of failed hunks. The comparison that gates the warning is checking against the wrong number entirely.
The successful hunk still gets written to the file either way. What's missing is the notice telling the user that happened.
The damage
No production incident or data loss is attached to this report — it's a code-review finding, not an observed failure in the wild. The risk it documents is narrower but still real: a user believes a diff either fully applied or fully failed, when in fact a partial write landed on disk with no signal that it happened. The reporter suggested the fix directly (count failed hunks before the join, not after) but no maintainer response or patch had landed as of publication.
Worth noting: this is the third silent-partial-success report filed against Aider within the same week, in three different code paths — edit-format auto-selection and headless-mode exit codes are the other two. Same shape each time: work is partially or fully altered with no signal reaching the user.
What this incident does and doesn't establish
This establishes a specific, named logic bug in a specific function, with the faulty comparison identified precisely enough to fix in one line. It does not establish that anyone has hit this in production, or that the bug is severe — no reproduction steps or user-facing report accompany the source-reading. It's an unconfirmed, unfixed defect, not a confirmed outage.
Status
Open, unconfirmed by maintainers, unpatched as of this write-up.
Full incident record, severity scoring (4.2 / medium), and sourcing: STUPID-2026-0080
This is one of 80+ verified, severity-scored AI agent incidents documented at StupidLLM, an open incident database for AI coding agent failures.
Top comments (0)