Dependabot silently fails to create PRs when a branch named "dependabot" exists

[iainbeeston]

Package ecosystem: All (reproduced with github-actions and npm)

dependabot.yml content:

version: 2
updates:
  - package-ecosystem: github-actions
    directory: '/'

What you expected to see, versus what you actually saw:

When a repository has a branch named dependabot, the Dependabot updater runs successfully and reports PRs as "created" in its results table, but the PRs are never actually created. There is no error reported - the workflow run completes with a success status.

This happens because Dependabot creates branches under the dependabot/ namespace (e.g. dependabot/github_actions/actions/checkout-6), and Git cannot have both refs/heads/dependabot (a branch) and refs/heads/dependabot/... (a sub-path) at the same time due to a ref naming conflict.

Expected: Dependabot should fail with a warning message explaining that branch creation failed due to a ref conflict with an existing dependabot branch.

Actual: The run succeeds, the results table shows | created | ..., but no branches or PRs are created. This fails silently with no indication of the problem.

Example output from a successful run that created no actual PRs:

+------------------------------------------------------------------------+
|                  Changes to Dependabot Pull Requests                   |
+---------+--------------------------------------------------------------+
| created | google-github-actions/upload-cloud-storage ( from 2 to 3 )   |
| created | actions/setup-node ( from 4 to 6 )                           |
| created | google-github-actions/deploy-cloud-functions ( from 3 to 4 ) |
| created | google-github-actions/auth ( from 2 to 3 )                   |
| created | actions/checkout ( from 4 to 6 )                             |
+---------+--------------------------------------------------------------+

This affects all ecosystems, not just github-actions.

Images of the diff or a link to the PR, issue, or logs:

N/A (private repository), but the issue is reproducible by creating a branch named dependabot on any repository with Dependabot configured and dependencies that can be updated.

Smallest manifest that reproduces the issue:

Any repository with a .github/dependabot.yml config (the one above would work) and a branch named dependabot should reproduce this. The dependabot needs to exist.

[robaiken]

Hi @bflad 👋, thanks for the detailed write-up!

This is a known issue, we recently investigated the same root cause in #14098. As you correctly identified, having a branch named dependabot prevents Git from creating any dependabot/... branches due to a ref namespace conflict.

The silent failure happens because the updater doesn't actually do the branch creation itself, that happens in a separate service afterward and the failure doesn't surface back to the user. Agreed that improving that feedback is something we should look into.

For anyone hitting this, the fix is to delete the dependabot branch from your repository.

[yeikel]

I think that the action and/or updater workflow should consider adding a check for this and failing the job with an error. Can we ask Copilot to do this @robaiken? If not, I can send a PR

[robaiken]

@yeikel thanks for offering to take this on! I think we should handle this on the API side rather than in the action/updater. I can add a check there to catch the conflicting branch before we attempt to open the PR

[yeikel]

@yeikel thanks for offering to take this on! I think we should handle this on the API side rather than in the action/updater. I can add a check there to catch the conflicting branch before we attempt to open the PR

Thanks for the clarification. If this is implemented in the API, how do you envision the feedback being delivered? Would it happen when the create pull request endpoint is called?

I ask because if the error is swallowed by the API and not propagated back to the job execution, it will continue to cause confusion.

Beyond that, the reason I suggested implementing it in Core is that people who use Core directly, like me, would benefit instead of having to recreate the logic on our side.

[robaiken]

I ask because if the error is swallowed by the API and not propagated back to the job execution, it will continue to cause confusion.

@yeikel good point. If we don't handle this early we'll end up surfacing the error in insights after the updater has already run and the API has failed to open the PR. I think we could cancel the run before we run the updater. Happy for this change to go ahead if you still want to send the pr

[yeikel]

I ask because if the error is swallowed by the API and not propagated back to the job execution, it will continue to cause confusion.

@yeikel good point. If we don't handle this early we'll end up surfacing the error in insights after the updater has already run and the API has failed to open the PR. I think we could cancel the run before we run the updater. Happy for this change to go ahead if you still want to send the pr

@robaiken #14218