reviewdog: annotation failed: line is outside of the diff

Not specified by the original author.

TL;DR

The linter reported a finding on a line that git does not consider changed, and reviewdog can only annotate lines inside the diff. The usual cause is drift: the code was reformatted or rebased between the lint run and the diff, or the linter ran on whole files. Rebase onto the current base, re-run the linter on the exact checked-out code, and keep the filter on changed lines. The line numbers have to agree.

The error

reviewdog: annotation failed: line is outside of the diff

Steps

1. Verify the flagged line is outside the diff

Take a failing file and line number from the log, then check the actual diff:

git diff origin/main...HEAD -- path/to/file

Expected output: the flagged line number falls outside every hunk, confirming the mismatch.

2. Check for drift between lint and diff

Look at the job order: does a format step, a rebase, or a generated-code step run between the linter and reviewdog? Any rewrite shifts line numbers. Expected output: you can identify the step that moved the lines.

3. Rebase onto the current base

Update the branch so the diff reviewdog sees matches the code the linter saw:

git fetch origin
git rebase origin/main
git push --force-with-lease

Expected output: a fresh diff with no stale hunks.

4. Re-run the linter on the exact checkout

Run the linter after the final checkout state, not on cached results from an earlier job. Pipe its fresh output straight into reviewdog. Expected output: linter line numbers match the diff hunks.

5. Keep filtering on changed lines

Confirm the reporter uses diff-aware filtering:

reviewdog -filter-mode=diff_context

Expected output: findings on unchanged lines are skipped instead of erroring.

6. Re-run the review step

Expected output: annotations post cleanly with no outside-of-diff errors.

When to use

• reviewdog fails with the line-outside-diff error
• A format or codegen step runs in the same job as the linter
• The PR was rebased while CI was running

When not to use

• Diff parse errors (reviewdog cannot read the diff at all)
• Annotation permission errors
• Linter config or crash problems

Tool compatibility

• reviewdog v0.14 and later
• Any linter piped into reviewdog (eslint, flake8, golangci-lint, and others)
• GitHub check runs and PR review reporters

Variant phrasings

reviewdog cannot annotate line outside diff

Same fix. The mapping between linter output and diff hunks broke.

annotation failed after rebase during CI

The rebase moved the lines mid-run. Re-run the linter after the final rebase.

reviewdog line mapping wrong on generated files

Generated files shift line numbers between generation and lint. Lint the generated output in place.

Why it happens

reviewdog translates each linter finding into a diff position (file plus line inside a hunk). If the linter analyzed different bytes than the diff describes, the position does not exist and the annotation call fails. Anything that rewrites the file between those two moments breaks the mapping.

Edge cases

• Line-ending changes (CRLF to LF) rewrite every line of a file. Normalize line endings before linting.
• Linters that report the end line of a range instead of the start can land one line past a hunk. diff_context filtering absorbs most of these.
• Multi-line findings on single-line hunks: keep the linter output to single-line positions where possible.
• Concurrent pushes to the PR branch during CI: consider concurrency cancellation so a stale run never posts.

Provenance

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

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

Thread query: reviewdog: annotation failed: line is outside of the diff

TL;DR: The linter reported a finding on a line that git does not consider changed, and reviewdog can only annotate lines inside the diff. The usual cause is drift: the code was reformatted or rebased between the lint run and the diff, or the linter ran on whole files. Rebase onto the current base, re-run the linter on the exact checked-out code, and keep the filter on changed lines. The line numbers have to agree.

Not specified by the original author.

TL;DR

The base ref does not exist in the CI checkout. reviewdog asks git for the diff against origin/main, but the runner never fetched that ref, which is the normal result of a shallow or single-branch clone. Fetch the full history (or at least the base branch) before the diff step and the error goes away. This is a checkout problem, not a reviewdog problem.

The error

reviewdog: error: fail to get git diff: ambiguous argument 'origin/main...HEAD'

Steps

1. Confirm the base ref is missing

git rev-parse --verify origin/main

Expected output right now: a fatal "unknown revision" message. That confirms the diagnosis. After the fix, this command prints a commit SHA.

2. Inspect the checkout step

Open the workflow and find the checkout step. Look for fetch-depth: 1 (the default) or a missing fetch-depth key, which means shallow, single-branch history. Expected output: you can see exactly which step produces the broken checkout.

3. Fetch the full history

Change the checkout step to fetch everything:

- uses: actions/checkout@v4
  with:
    fetch-depth: 0

Expected output: the next run fetches all branches and tags, and the verify command from step 1 prints a SHA.

4. Or fetch just the base ref

If a full clone is too slow for a big repo, keep the shallow clone and add an explicit fetch before reviewdog runs:

git fetch origin main:refs/remotes/origin/main

Expected output: the ref is created locally without downloading the whole history.

5. Match the real default branch name

If the repo's default branch is master or develop instead of main, use that name in the fetch and in the diff range. Check the repo settings for the default branch name. Expected output: the diff range resolves against a ref that actually exists.

6. Re-run the reviewdog step

Push the workflow change and re-run the failed job. Expected output: reviewdog exits 0 and posts annotations instead of the git error.

When to use

• The reviewdog CI step fails with "ambiguous argument" on the base ref
• The workflow uses the default shallow checkout
• PRs from forks fail while same-repo PRs pass

When not to use

• reviewdog diff parse errors (malformed hunks, binary patches)
• Annotation posting failures (permissions, line mapping)
• The ref exists locally but the diff is empty

Tool compatibility

• reviewdog v0.14 and later, all reporters
• actions/checkout v3 and v4 (fetch-depth behaves the same)
• git 2.25 and later (refspec fetch syntax)

Variant phrasings

reviewdog ambiguous argument origin/master...HEAD

Same fix. Swap in whatever the default branch is called. Repos created before late 2020 usually default to master.

reviewdog fails on pullrequesttarget with missing base

pullrequesttarget checks out the base repo, but a shallow fetch still skips the base ref. The explicit fetch in step 4 works here too.

git diff ambiguous argument in GitHub Actions

This is the same underlying git behavior outside reviewdog. Any tool that diffs against a remote ref needs that ref fetched first.

Why it happens

The triple-dot range origin/main...HEAD needs both endpoints to exist locally. A shallow checkout only downloads the PR head commit, so origin/main is unknown and git cannot compute the merge base. reviewdog surfaces git's complaint verbatim.

Edge cases

• Force-pushed PRs: the fetched base is fine, but a stale PR head can still confuse the diff. Re-fetch the PR ref too.
• Very large repos: fetch-depth 0 can add minutes. Prefer the targeted single-ref fetch in step 4.
• Tags-only workflows: if the diff range uses a tag, fetch tags explicitly with a tag refspec.
• Monorepos with sparse checkout: the ref problem is independent of sparse paths, but confirm the sparse config still includes the files reviewdog needs.

Provenance

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

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

Thread query: reviewdog: error: fail to get git diff: ambiguous argument 'origin/main...HEAD'

TL;DR: The base ref does not exist in the CI checkout. reviewdog asks git for the diff against origin/main, but the runner never fetched that ref, which is the normal result of a shallow or single-branch clone. Fetch the full history (or at least the base branch) before the diff step and the error goes away. This is a checkout problem, not a reviewdog problem.

Not specified by the original author.

TL;DR

Reviewdog skips every file when its filter patterns match nothing in the diff. Usually the include or exclude globs use the wrong path prefix (repo-root vs subdirectory) or the diff paths changed shape. Print the changed file list, test the filter against it, and fix the pattern. An empty filter match is a config bug, not a clean bill of health.

The query

reviewdog error: no filter matched for changed files

Use this when

• Reviewdog exits with "no filter matched for changed files" on a PR that changed files.
• Reviewdog posts zero findings on PRs that clearly have lint issues.
• The filter config was recently added or edited.

Not for

• reviewdog: error: fail to parse diff: unexpected hunk header (that is a diff-format problem).
• annotation failed to post: resource not accessible by integration (that is a permissions problem).
• A linter that genuinely found nothing (then reviewdog correctly posts nothing).

Steps

Step 1: List the changed files reviewdog should see

git diff --name-only origin/[base]...HEAD

Expected output: the actual changed paths, relative to the repo root. Keep this list open. Every filter pattern must match at least one of these paths, or the filter is wrong by definition.

Step 2: Inspect the filter flags in the workflow

grep -n -A 10 "reviewdog" .github/workflows/[workflow].yml

Expected output: the reviewdog invocation with its -filter-mode and any include or exclude patterns. Common culprit: patterns anchored at a subdirectory while the diff paths are repo-root relative, or vice versa.

Step 3: Test the glob semantics

echo "changed: src/api/handler.go"
echo "pattern **/*.go matches from repo root; *.go does not match nested paths"

Expected output: the realization that reviewdog uses doublestar globs. *.go matches only top-level files. **/*.go matches at any depth. Most "no filter matched" cases are a missing **/ prefix.

Step 4: Verify reviewdog receives the full diff

git diff origin/[base]...HEAD | head -20
git diff origin/[base]...HEAD | wc -l

Expected output: a non-empty diff piped to reviewdog. If the workflow passes a truncated or empty diff (wrong base ref, shallow clone), the filter has nothing to match regardless of the pattern.

Step 5: Fix the pattern and re-run

- uses: reviewdog/action-golangci-lint@v2
  with:
    filter_mode: diff_context
    fail_level: error

Expected output: with the corrected pattern and filter_mode appropriate to the use case (diff_context for new issues, added for added lines only), reviewdog posts findings on the changed files instead of the no-match message.

Step 6: Add a guard so silent zero-findings fail loudly

changed=$(git diff --name-only origin/[base]...HEAD | wc -l)
[ "$changed" -gt 0 ] && echo "reviewdog must report or explain"

Expected output: a CI assertion that fails the step when the PR changed files but reviewdog reported nothing and gave no reason. The next filter regression becomes a red build, not a silent pass.

Variant phrasings

reviewdog error: all golangci-lint checks skipped, no files matched

Same filter mismatch, one level down: the linter ran but its file selection matched nothing. Fix the linter's path config the same way.

reviewdog error: diff is empty when agent tried to review a draft PR

The diff input was empty, so every filter trivially matched nothing. Fix the diff generation (fetch the base ref, unshallow the clone) before touching filters.

reviewdog posts nothing on PRs but works on main

The base ref differs between the two contexts. Step 4's diff check catches it.

Why it happens

Filter mode defaults to matching changed lines, and the include/exclude globs are evaluated against diff paths that are relative to the repo root. When the pattern was written against a different root (a subdirectory checkout, a monorepo package path, a docs example), nothing matches, reviewdog finds no files to check, and it reports the no-match message instead of failing. The agent reads "no findings" as "clean PR" and moves on, which is exactly backwards.

Edge cases

• Renamed files appear in the diff with old-to-new path syntax. A filter matching the old path misses the new one. Anchor on the new path.
• filter_mode: nofilter disables filtering entirely and checks the whole codebase. Useful for debugging, but do not ship it as the fix. It will drown the PR in pre-existing findings.
• Shallow clones (fetch-depth: 1) cannot produce the merge-base diff. The diff is empty, the filter matches nothing, and the error message blames the filter.
• On monorepos, run one reviewdog invocation per package with package-rooted patterns rather than one invocation with a pattern that tries to cover everything.
• If the linter itself crashed, reviewdog may report no findings instead of the crash. Check the linter's exit code independently.

Provenance

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

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

Thread query: reviewdog error: no filter matched for changed files

TL;DR: Reviewdog skips every file when its filter patterns match nothing in the diff. Usually the include or exclude globs use the wrong path prefix (repo-root vs subdirectory) or the diff paths changed shape. Print the changed file list, test the filter against it, and fix the pattern. An empty filter match is a config bug, not a clean bill of health.