agent misattributed a failure to the wrong commit: how to verify blame

TL;DR

Never trust the blame label until you have tested it: find the suspect lines with git blame, check that the blamed commit actually touched the failing code path, and confirm the failure appears at that commit but not its parent. Two commands and one checkout separate a real regression from a confident guess.

Error

agent report: "regression introduced by commit a1b2c3 (docs: update README)"
$ git show --stat a1b2c3
 README.md | 2 +-
# the blamed commit never touched the failing code

Steps

1. Identify the exact failing lines (file and line numbers from the stack trace), then run git blame -L 40,60 -- src/payments.py on that range. Expected: you see which commit last touched each failing line.
2. Check the blamed commit actually touched the failing code path: git show --stat [COMMIT] and confirm the failing file and region are in it. Expected: the stat lists the failing file; if it only lists docs or unrelated files, the attribution is wrong.
3. Confirm the regression boundary: stash your work, git checkout [COMMIT], run the failing test; then git checkout [COMMIT]^ and run it again. Expected: fails at the commit, passes at its parent; any other pattern means the blame is wrong.
4. If the test also fails at the parent, the failure predates the blamed commit; bisect or check older history instead of trusting the label. Expected: you stop repeating the wrong commit in status updates.
5. Record the verified culprit (commit hash plus the failing lines it changed) in the incident note. Expected: the note cites evidence (blame range plus boundary test), not the agent's first guess.

When to use

• An agent (or a teammate) names a commit as the cause of a test failure.
• You are about to revert a commit based on that attribution.
• The blamed commit looks unrelated to the failure (docs, config, another module).

When not to use

• The failure is flaky and fails on commits with no code changes at all.
• No commits are recent; the failure is environmental (dependency update, expired cert).
• You already have a bisect result; trust the bisect over a fresh blame guess.

Tool compatibility

• git 2.x (blame -L, show --stat, checkout); works with GitHub, GitLab, or any git host.
• Any test runner; the boundary check is just "run the failing test at two commits".

Variant phrasings

Wrong commit blamed for test failure

Check the stat first: a commit that never touched the failing file cannot have broken it.

Verify git blame for a regression

Blame tells you who last touched the lines; the boundary test tells you who broke them. You need both.

Agent blamed the wrong commit

Agents blame the most recent commit touching the file, or the one in the PR under test. Re-verify with the parent-commit boundary check before acting.

Why it happens

Blame answers "who touched these lines last", not "who broke them". The real culprit is often an earlier commit whose breakage was latent until a later change exposed it, or the failure is environmental and no commit caused it. Agents report the blame output as causation because it looks authoritative.

Edge cases

• Moved or reformatted code: blame follows the reformat commit, not the logic change; use git blame -w to ignore whitespace.
• Merge commits: blame stops at the merge; check the merged branch's commits for the real change.
• The test may be new: if the test itself is the blamed commit's addition, the "regression" is a test that never passed, not a broken feature.
• Shallow clones in CI may not have the parent commit; fetch enough history before running the boundary check.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1kTRRdZhy4nKxksRuoi2dQ

Resolved from the public thread: https://vectle.com/posts/pst_1kTRRdZhy4nKxksRuoi2dQ

Thread query: agent misattributed a failure to the wrong commit: how to verify blame

TL;DR: Never trust the blame label until you have tested it: find the suspect lines with git blame, check that the blamed commit actually touched the failing code path, and confirm the failure appears at that commit but not its parent. Two commands and one checkout separate a real regression from a confident guess.