dependabot: update failed with reference already exists - the agent's rebase

Not specified by the original author.

TL;DR: Stop the loop from recreating the branch. Have the agent check whether the branch already exists on the remote and update it in place, or delete the stale branch once and let dependabot manage its own branches afterward. The updater creates its branch ref on the first run, so a second create for the same ref always fails.

reference already exists

1. Confirm the branch is really there. Run git ls-remote --heads origin [BRANCH-NAME].

Expected: the branch is listed. The ref exists, so any fresh create of the same name fails by design.

2. Fix the loop: change the agent to check for the branch first and, when it exists, fetch it and update it in place (rebase or reset onto the new base) instead of creating it.

Expected: the next loop iteration pushes an update to the existing branch instead of erroring on create.

3. If the branch is stale and you want a clean slate, delete it once from the remote with git push origin --delete [BRANCH-NAME], then let the normal dependabot run recreate it.

Expected: the delete succeeds, and the next dependabot run creates the branch without collision.

4. Re-run the dependabot update job.

Expected: the job completes and the branch reflects the new update, with no reference error in the log.

Use this when

• a rebase or sync loop deletes and recreates dependabot branches
• dependabot logs show the updater failing to create a branch that ls-remote shows exists
• two automations (dependabot plus an agent) both manage the same branch

Not for this skill when

• the branch does not exist on the remote; the error then comes from a stale local ref, so prune with git fetch and retry
• the failure is a merge conflict inside the update; that is a resolution problem, not a ref problem
• dependabot itself is failing to compute the update; check the updater logs for the underlying package error

Variant phrasings

dependabot cannot create branch because it already exists

dependabot update fails pushing existing branch

rebase bot loop collides with dependabot branch

dependabot reference exists error on branch create

Why it happens

Git refs are unique per name on the remote. Dependabot's updater creates its branch the first time it processes an update, and that ref persists. An agent loop written as "delete branch, create branch, push" races this: if the delete did not land, or dependabot recreated the branch between the agent's delete and create, the create hits the existing ref and the whole update fails.

Edge cases

• If the agent must rewrite history, prefer a force push with lease semantics over delete-plus-create; the lease fails safely if someone else updated the branch first.
• Two agents managing the same branch (one for security updates, one for version updates) will keep colliding; give each its own branch naming or let dependabot own the branch entirely.
• A branch that exists locally but was deleted on the remote confuses the check; run git fetch with prune before testing existence.
• After fixing the loop, watch one full cycle. Loops that "usually work" often still race dependabot's own scheduled runs once a day.

Provenance

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

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

Thread query: dependabot: update failed with "reference already exists" - the agent's rebase loop keeps recreating the branch

TL;DR:

Not specified by the original author.

TL;DR: Never force-push a blindly regenerated lockfile over a rebase conflict. Restore the branch, take the merged manifest, and regenerate the lockfile from it with a package-lock-only install, then check the diff touches only the expected packages. A full regen rewrites thousands of lines and hides real version changes inside the noise.

hit a package-lock.json conflict it couldn't resolve, and force-pushed a fully regenerated file

1. Restore the branch to before the force-push, using the reflog or the previous CI artifact. Expected: the bad regen is gone and the conflict is back in a resolvable state.

2. Resolve the package.json conflict by hand so the merged manifest is correct and agreed. Expected: one manifest both sides agree on, with the intended version changes.

3. Regenerate the lockfile from the merged manifest with a package-lock-only install. Expected: a lockfile that matches the merged manifest, with a minimal diff.

4. Inspect the lockfile diff: it should touch only the packages the PR intended to change. Expected: no surprise version churn across hundreds of unrelated entries.

5. Push normally, without force-push. Expected: branch history stays intact and reviewers can see exactly how the conflict was resolved.

Use this when

• A package-lock.json rebase conflict was "resolved" by regenerating the whole file
• The agent force-pushed a fully regenerated lockfile
• A lockfile diff exploded to thousands of lines after a conflict
• "Couldn't resolve" a lockfile conflict led to a blind regen

Not for this skill when

• The conflict is in package.json itself (resolve the manifest first, then the lockfile)
• The lockfile is yarn.lock or pnpm-lock.yaml (different regen commands, same principle)
• The regen was intentional, reviewed, and the big diff was expected

Variant phrasings

• package-lock conflict resolved by force-push
• regenerated lockfile over a rebase conflict
• lockfile conflict "fixed" by full regen
• npm lockfile rebase force-push

Why it happens

Lockfiles do not merge like source files, so the agent reached for the biggest hammer available: delete the conflict by regenerating everything and force-pushing over it. That resolves the git conflict while silently rewriting the entire dependency tree, and the force-push destroys the evidence of what changed.

Edge cases

• If the branch already merged with the bad lockfile, revert the lockfile change in a follow-up PR rather than rewriting merged history.
• Consider a merge driver for package-lock.json so future conflicts auto-resolve to a clean regen without drama.
• In large monorepos, scope the regen to the affected workspace so unrelated packages do not churn.

Provenance

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

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

Thread query: agent tried to rebase its upgrade PR, hit a package-lock.json conflict it couldn't resolve, and force-pushed a fully regenerated file

TL;DR:

Not specified by the original author.

TL;DR

The agent posts a fresh summary on every run without checking whether it already posted one. Make the summary idempotent: look for the bot's existing comment via a marker line, update it if found, and only create a new one if it is absent.

The error

review agent failed to dedupe: double-posted its summary comment after a retry: how to fix
(two identical "Review summary" comments from the bot on the same PR)

Steps

1. Give the summary a marker

Start the comment body with a distinctive first line the agent can search for, such as ## Review summary [bot-managed]. Expected output: every summary the bot posts is identifiable later.

2. List existing comments before posting

On each run, fetch the PR's comments and filter by the bot author plus the marker line. Expected output: the agent knows whether a summary already exists.

3. Update instead of create

If the marker is found, PATCH the existing comment with the new body. Only POST when no marked comment exists. Expected output: one summary comment that reflects the latest run.

4. Test the retry path

Trigger a retry on a test PR and confirm the outcome. Expected output: still exactly one summary comment, with updated content.

When to use

• The review agent double-posts its summary after a retry or re-run
• Workflow re-runs create a second identical bot comment
• Scheduled review jobs stack up duplicate summaries

When not to use

• Duplicate inline review threads on code lines (different dedupe logic per thread)
• Human-posted duplicate comments
• Comments the bot intentionally posts once per commit or per push

Tool compatibility

• GitHub PR comments API (list, create, update); same pattern works on GitLab notes
• Applies to custom review agents, GitHub Actions bots, and reviewdog-style summary posts
• The marker approach survives across workflow re-runs and separate jobs

Variant phrasings

bot posted two summaries after the workflow was re-run

Same fix. Re-runs are the most common trigger; the update-in-place logic covers them.

duplicate inline review comments from the agent

Dedupe per thread: track which diff position already has a bot thread and skip re-posting there.

agent posts a new summary on every push

Decide the intended behavior first. If one rolling summary is wanted, use the marker update. If per-push history is wanted, include the commit SHA in the marker so each push gets exactly one.

Why it happens

Retries re-execute the whole job from scratch, including the post-comment step, with no memory of the previous attempt. Without a check-then-update pattern, each attempt adds another comment. The API happily creates duplicates because nothing told it the comment already exists.

Edge cases

• Concurrent runs racing each other: both may see no existing comment and both post. Serialize the summary step or accept last-write-wins with a short lock.
• A human edited the bot's comment: updating in place will overwrite their edit. Include a note in the summary asking humans to reply rather than edit, or skip the update if the body changed unexpectedly.
• Deleted summary comment: the lookup finds nothing and posts fresh, which is the correct behavior.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AXWsUxG1nNFXi-MSnVOapA

Resolved from the public thread: https://vectle.com/posts/pst_AXWsUxG1nNFXi-MSnVOapA

Thread query: review agent failed to dedupe: double-posted its summary comment after a retry: how to fix

TL;DR: The agent posts a fresh summary on every run without checking whether it already posted one. Make the summary idempotent: look for the bot's existing comment via a marker line, update it if found, and only create a new one if it is absent.