Individual PRs incorrectly opened (and then immediately closed) when grouped updates enabled

[edmorley]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

Cargo

Package manager version

1.73

Language version

1.73

Manifest location and content before the Dependabot update

https://github.com/heroku/buildpacks-python/blob/76e1c6f822dfa9567ad0072b9e082547891c35e8/Cargo.toml
https://github.com/heroku/buildpacks-python/blob/76e1c6f822dfa9567ad0072b9e082547891c35e8/Cargo.lock

dependabot.yml content

https://github.com/heroku/buildpacks-python/blob/76e1c6f822dfa9567ad0072b9e082547891c35e8/.github/dependabot.yml

Updated dependency

No response

What you expected to see, versus what you actually saw

I have grouped updates enabled for this repo, so I expect single-dependency PRs not to be opened unless they are for dependencies not included in the group (or say for other edge cases, such as it being an out-of-schedule security PR etc).

Prior to this issue occurring, there were two Dependabot PRs open in the repo:

• Bump the rust-dependencies group with 1 update heroku/buildpacks-python#118 (a grouped PR)
• Bump rustix from 0.38.14 to 0.38.19 heroku/buildpacks-python#124 (an out-of-schedule security update PR)

At this point I then triggered a manual Dependabot run (thinking "well if we need to do the security update PR, I might as well update all the things at once"), using Insights -> Dependency graph -> Dependabot -> etc.

The new Dependabot run then proceeded to incorrectly make two new single-dependency PRs for dependencies that should be in a group:

• Bump flate2 from 1.0.27 to 1.0.28 heroku/buildpacks-python#125
• Bump serde from 1.0.188 to 1.0.189 heroku/buildpacks-python#126

Immediately after that, Dependabot created the grouped PR after all:

• Bump the rust-dependencies group with 2 updates heroku/buildpacks-python#127

...and then proceeded to close one of the erroneously opened single update PRs (as "superseded"), but not the other?

Today, I then triggered a manual Dependabot run again, and it closed out the single-dependency update PR that hadn't been immediately closed after opening yesterday.

It seems like there is some race condition or other weirdness going on here.

Native package manager behavior

No response

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

Dependabot run logs:
https://github.com/heroku/buildpacks-python/network/updates/737488004

Smallest manifest that reproduces the issue

No response

[edmorley]

I've just had another instance occur on a different repository. One thing the two repositories had in common, was that they both already had open grouped PRs plus a security update PR open at the time of the manually triggered Dependabot run.

In this case, the new grouped PR was:

• Bump the rust-dependencies group with 3 updates heroku/languages-github-actions#161

And the incorrectly opened single-dependency update PR was:

• Bump toml_edit from 0.20.0 to 0.20.2 heroku/languages-github-actions#162

[edmorley]

This happened again in:
heroku/languages-github-actions#165
(opened then immediately closed as superseded by heroku/languages-github-actions#166)

[broksonic21]

I have seen examples of this recently in Package.json/npm in private repositories with Github-hosted dependabot, so does not appear to be Cargo exclusively.

[edmorley]

Some Ruby examples this time:
https://github.com/heroku/buildpack-registry/pull/397
https://github.com/heroku/buildpack-registry/pull/398

Logs:
https://github.com/heroku/buildpack-registry/network/updates/743867732 ("Version update 743867732")
https://github.com/heroku/buildpack-registry/network/updates/743867745 ("Rebase update 743867745")

[edmorley]

Some more instances of this in another repo:
buildpacks/pack#1974
buildpacks/pack#1973
buildpacks/pack#1972
buildpacks/pack#1971

[jakecoffman]

Sorry for the delay. This is hopefully fixed going forward!

[edmorley]

@jakecoffman The issue here has been resolved, but it seems a new regression has been introduced? I've filed #8558 for that.