Dependabot opens new PR after closing existing one

[bkoelman]

Is there an existing issue for this?

• [x] I have searched the existing issues

Package ecosystem

nuget

Language version

C#

What you expected to see, versus what you actually saw

This started happening a few weeks ago. When I close a PR opened by Dependabot, it adds the following message:

OK, I won't notify you again about this release, but will get in touch when a new version is available...

And then a few hours/days later, it opens a new PR with the exact same change.

For example, I closed https://github.com/json-api-dotnet/JsonApiDotNetCore/pull/1861, and then https://github.com/json-api-dotnet/JsonApiDotNetCore/pull/1862 got created.

I expect Dependabot to behave as it says: skip this version.

[yeikel]

I think that this may be related to #13320

[bkoelman]

How is that related? That issue is about not opening PRs, or very late. This one is about the opposite: creation of unexpected PRs.

[yeikel]

How is that related? That issue is about not opening PRs, or very late. This one is about the opposite: creation of unexpected PRs.

I think that it is related because It suggests that they were queued up for creation at the same time and when the queue picked them it caused duplication

But maybe it is not related. I don't have enough information from my side and it is just a guess. Sorry for the confusion!

[bkoelman]

I don't think that's the case. A new PR is opened immediately after I rerun the updater.

[yeikel]

I don't think that's the case. A new PR is opened immediately after I rerun the updater.

So duplication continues when you run the updater? That's interesting context and suggests something else

[bkoelman]

Yes. As if the "skip this version" is being ignored, or wasn't recorded properly in the first place. Every week the updater creates a new PR. And every week I close it.

[legrab]

I can confirm, I keep getting an update back every night for the same packages that I tried closing with @dependabot close as well as manual PR close before.

Current packages are Microsoft.Extensions.Identity.Stores from 9.0.11 to 10.0.0 Serilog.AspNetCore from 9.0.0 to 10.0.0

MS packages are "pinned" with range as [9.0.11, 10.0.0) and even though it's "by design" (declined request in PR) to ignore the range limit, the package PR was closed a million times and yet comes back every single day per scheduled runs.

This has not been the case before, started a few weeks ago. Note that we keep the repos clean from pending updates, so I can't confirm if it could have happened before, but the timing seems strikingly close to the appearance of net10

Interesting is that not all pinned net10 MS packages show up, only the one mentioned above, although this is the only one that has no clear explicit reference to .net framework. The Identity.Stores does reference some other MS.Extension package that transitively references another that is tied to framework version, though, hence we can't update. My reasoning here is that dependabot seems to recognise the explicit framework block on the other packages and skips suggesting them which is great, however, when that's not there, it keeps suggesting the new version. I don't mind transitive framework requirements not being recognised, that seems to be a generic nuget issue, but felt it's worth mentioning in case it helps investigating this issue.

[yeikel]

I tried reproducing this in a fork and couldn't get it to happen, but It's definitely happening based on your logs

Can you add the ignore configuration in thedependabot.yml file and see if that helps?

I understand that comments should be honored, but I am curious to see where the issue is

[bkoelman]

Tried that, but doesn't help. A new PR just got created. See https://github.com/json-api-dotnet/JsonApiDotNetCore/blob/master/.github/dependabot.yml.

[brettfo]

Regarding the NuGet updater, I don't think there's anything that can be done there. When a run is started an updater is only given a job file that specifies what can and can't be done. A (potentially large) JSON object is output to the log at the start of the run. In the instances where a PR was re-opened right after an old one was closed and the bot reported that it wouldn't try that again, that information wasn't conveyed via the job file, but the ignore section of dependabot.yml is honored so that's why manually ignoring a given package works in that case.

For example this ignore condition is reflected in the job JSON at the top of the log and this line in the log shows that ignore condition was honored and no call to the endpoint create_pull_request was made.

I'll see if I can track down what happens to the bot comment that reported that it would ignore that version.

[bkoelman]

@brettfo Sorry, I misinformed you. A PR was created, but in another repository, which doesn't include the exclusion rule. See https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/145.

[yeikel]

Could you clarify which one is the duplicate here?

Because https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pulls?q=is%3Apr+%22Microsoft.Extensions.Caching.Memory%22 only returns a result for me

[yeikel]

I just saw that these were opened:

https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/148 https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/147 https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/145

I do understand now what you mean because based on the message from Dependabot

OK, I won't notify you again about this release

That message suggests that Dependabot created a "dynamic/runtime" ignore configuration that the updater job should respect to not send any more pull request for Microsoft.Extensions.Caching.Memory v10.0.0

Based on the job though, I do not see any "runtime" ignore version captured.

It captured @dependabot ignore from previous comments as well as the manual entries in dependabot.yml. But It does not seem that it created a "runtime ignore" entry for pull request closure

Based on the comment above, we should expect to see something like

{
      "dependency-name": "Microsoft.Extensions.Caching.Memory",
      "version-requirement": "10",
      "update-types": null,
      "source": "Pull request closure?",
      "updated-at": "2025-08-16T13:00:42Z"
    },

Are "dynamic/runtime" ignore options expected to be captured on closure as the comment suggests? @brettfo

Ignore conditions from the latest run

"ignore-conditions": [
    {
      "dependency-name": "FluentAssertions",
      "version-requirement": ">= 8.a, < 9",
      "update-types": null,
      "source": "@dependabot ignore command",
      "updated-at": "2025-08-16T13:00:42Z"
    },
    {
      "dependency-name": "JsonApiDotNetCore*",
      "version-requirement": ">= 0",
      "update-types": null,
      "source": ".github/dependabot.yml",
      "updated-at": "2024-08-31T08:14:54Z"
    },
    {
      "dependency-name": "Microsoft.AspNetCore*",
      "version-requirement": null,
      "update-types": [
        "version-update:semver-major"
      ],
      "source": ".github/dependabot.yml",
      "updated-at": "2024-08-31T08:14:54Z"
    },
    {
      "dependency-name": "MongoDB.Driver*",
      "version-requirement": ">= 0",
      "update-types": null,
      "source": ".github/dependabot.yml",
      "updated-at": "2024-08-31T08:14:54Z"
    }
  ],

[bkoelman]

For the json-api-dotnet/JsonApiDotNetCore.MongoDb repository, this is what happened:

1. It opened https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/145, which I closed
2. Ran the updater, which created https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/147, which I closed
3. Ran the updater, which created https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/148

[yeikel]

I am pretty confident that if you comment @dependabot ignore this major version it will not raise more pull requests for v10

But what I'd like to know as well is if @dependabot ignore this major version is supposed to happen automatically on manual pull request closure, or if the message from Dependabot means something else

[bkoelman]

Here's the full message:

and:

It used to work like that. So I'm assuming that Dependabot internally stores what the user asked for, independent of the ignore rules in the git repo.

[bkoelman]

The way it used to work was that closing the PR manually or running the close command would remember to skip this patch version. A new PR would be opened as soon as any newer version becomes available.

[bkoelman]

I suspect this is not a NuGet-specific problem. I've seen the same issue happen with version updates for GitHub Actions workflows.

[yeikel]

I don't have any further access to check this one. But what happens when you run this?

@dependabot show Microsoft.Extensions.Caching.Memory ignore conditions

[bkoelman]

https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/148#issuecomment-3608828016

[bkoelman]

Do you want me to try running "ignore this major version"?

[yeikel]

I think we should wait for @brettfo or any other Dependabot team that can help here because your usage seems correct to me and this should not be happening from what I understand

I tried to reproduce this for maven and I could not replicate this so it is unclear what's happening

I suspect that short term, your best bet will be to add a manual ignore entry to dependabot.yml. I agree that it is not ideal or expected.

[bkoelman]

Ok, thanks. I'll leave the ignore rule in JsonApiDotNetCore, and leave it out in JsonApiDotNetCore.MongoDb, so we have something to test with.

[yeikel]

I also confirmed that closing does not create any ignore conditions:

No ignore conditions found for the dependency com.squareup.retrofit2:retrofit

But it also does not create any further pull requests as we'd expect.

Something that I do see in my logs is this:

updater | 2025/12/03 21:16:46 INFO <job_1173410437> Pull request #5 already exists for com.squareup.retrofit2:retrofit with latest version 3.0.0

But I could not see this similar "already exists" log in your workflow logs

[yeikel]

@bkoelman Can you close the pull request and run Dependabot again? I am curious to see if we can see the "already exist" log or if we just see a third PR

[bkoelman]

Closed https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/148 and started another updater run. Log at https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/network/updates/1173436840.

[bkoelman]

Now it opened https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/149, which I'm closing again and rerunning the updater. Log at https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/network/updates/1173440017.

[yeikel]

Thanks! That's plenty of evidence

I also find it odd that sometimes the update goes from 9.0.11 to 10.0.0, but then shortly after, it shows 8.0.1 to 10.0.0. It seems to be going back and forth on that

9 -> 10 : https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/149 8 -> 10 : https://github.com/json-api-dotnet/JsonApiDotNetCore.MongoDb/pull/148

I'm not very familiar with .NET, but I wouldn't expect this behavior. Is the current version in use 8 or 9? It shouldn't be both, right?

This suggests there might be a problem with the updater incorrectly detecting the starting version. I'm not sure if this is the root cause of the issue you are seeing, but it could be related as dependabot may be considering the closure voided if the starting version changes

In the updater logs, I see this

/usr/local/dotnet/current/sdk/10.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/home/dependabot/dependabot-updater/repo/test/TestBuildingBlocks/obj/project.assets.json' doesn't have a target for 'net9.0'. Ensure that restore has run and that you have included 'net9.0' in the TargetFrameworks for your project. [/home/dependabot/dependabot-updater/repo/test/TestBuildingBlocks/TestBuildingBlocks.csproj::TargetFramework=net9.0] CSC : warning AV2210: Pass -warnaserror to the compiler or add <TreatWarningsAsErrors>True</TreatWarningsAsErrors> to your project file (https://github.com/dennisdoomen/CSharpGuidelines/blob/5.7.0/_rules/2210.md) [/home/dependabot/dependabot-updater/repo/src/JsonApiDotNetCore.MongoDb/JsonApiDotNetCore.MongoDb.csproj::TargetFramework=net8.0] JsonApiDotNetCore.MongoDb -> /home/dependabot/dependabot-updater/repo/src/JsonApiDotNetCore.MongoDb/bin/Debug/net8.0/JsonApiDotNetCore.MongoDb.dll Restored /home/dependabot/dependabot-updater/repo/src/JsonApiDotNetCore.MongoDb/JsonApiDotNetCore.MongoDb.csproj (in 489 ms). Restored /home/dependabot/dependabot-updater/repo/test/TestBuildingBlocks/TestBuildingBlocks.csproj (in 494 ms). CSC : warning AV2210: Pass -warnaserror to the compiler or add <TreatWarningsAsErrors>True</TreatWarningsAsErrors> to your project file (https://github.com/dennisdoomen/CSharpGuidelines/blob/5.7.0/_rules/2210.md) [/home/dependabot/dependabot-updater/repo/src/JsonApiDotNetCore.MongoDb/JsonApiDotNetCore.MongoDb.csproj::TargetFramework=net10.0] JsonApiDotNetCore.MongoDb -> /home/dependabot/dependabot-updater/repo/src/JsonApiDotNetCore.MongoDb/bin/Debug/net10.0/JsonApiDotNetCore.MongoDb.dll

[bkoelman]

I'm not very familiar with .NET, but I wouldn't expect this behavior. Is the current version in use 8 or 9? It shouldn't be both, right?

We using multi-targeting to target frameworks net8.0, net9.0 and net10.0. I guess the following happens:

When closing a PR that updates from v8 to v10, Dependabot records that the user wants to skip v8 (correct). Then it opens a PR to update from v9 to v10 (correct). The user closes that PR too, indicating that v9 is also not desired. Dependabot then presumably overwrites its earlier recorded state, "skip v9", with "skip v10" instead of adding it to its existing knowledge, therefore the earlier intent is lost. That could explain why it opens another PR to update from v8 to v10.

[bkoelman]

The log about NETSDK1005 looks fine to me. Our project contains the following:

<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="8.0.1"
    Condition="'$(TargetFramework)' == 'net8.0'" />

Which means: only reference Microsoft.Extensions.Caching.Memory for the net8.0 target framework.

Then it seems correct that the updater concludes there is no asset for that package for the target framework net9.0 and net10.0, which I believe is what the message tells.

What is odd, though, is that the Dependabot PR "solves" the problem by adding another, unconditional, package reference:

Instead of updating the existing one to:

<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="10.0.0"
    Condition="'$(TargetFramework)' == 'net8.0'" />

Which would be a correct update, because the package targets net8.0, net9.0 and net10.0 (but it's just not something we want to take).