Bundler version update fails when Gemfile cooldown excludes an already locked non-target dependency

[tim-gq]

Is there an existing issue for this?

I have searched existing issues. #15049 looks related, but that issue is about Dependabot's cooldown config affecting security updates. This case appears different: Bundler's Gemfile-level cooldown is excluding a version that is already present in Gemfile.lock while Dependabot is trying to update unrelated dependencies.

Package ecosystem

Bundler

Package manager version

The repository lockfile is BUNDLED WITH 4.0.13.

The failing job used:

ghcr.io/dependabot/dependabot-updater-bundler:b0fbdf190d2e14546c1896287d22016617d85a0f

Language version

The application uses Ruby 4.0.5.

Manifest location and content before the Dependabot update

/Gemfile:

# Reject public gems published less than 10 days ago (supply-chain protection).
source 'https://rubygems.org', cooldown: 10

ruby '4.0.5'

# Pin patched net-imap for CVE-2026-42245, CVE-2026-42246, CVE-2026-42256,
# CVE-2026-42257, CVE-2026-42258, CVE-2026-47240, CVE-2026-47241, and
# CVE-2026-47242.
gem 'net-imap', '>= 0.6.4.1'

/Gemfile.lock already contained:

net-imap (0.6.4.1)
...
net-imap (>= 0.6.4.1)
...
BUNDLED WITH
   4.0.13

dependabot.yml content

Relevant Bundler entry:

version: 2
updates:
  - package-ecosystem: "bundler"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "03:00"
      timezone: "America/Los_Angeles"
    open-pull-requests-limit: 10
    cooldown:
      default-days: 7

There are also allow, ignore, and groups rules, but net-imap is not one of the dependencies Dependabot was attempting to update in this run.

Updated dependency

Dependabot was attempting normal version updates for unrelated dependencies, including grouped/individual updates such as sentry-ruby, sentry-rails, sentry-sidekiq, rubocop, rack-cors, doorkeeper, datadog, oj, secure_headers, and bootsnap.

The run failed for each attempted update with the same net-imap resolver error.

What you expected to see, versus what you actually saw

Expected:

Dependabot should preserve the already locked net-imap 0.6.4.1 while resolving updates for unrelated dependencies, or otherwise invoke Bundler in a way that does not let the Gemfile source cooldown reject a version already recorded in Gemfile.lock.

This expectation comes from Bundler/RubyGems cooldown semantics: cooldown applies during resolution, but versions already recorded in Gemfile.lock should remain usable. See the RubyGems discussion text: "Versions already recorded in Gemfile.lock are not subject to cooldown checks."

Actual:

Dependabot failed the Bundler version-update job because Bundler excluded net-imap 0.6.4.1 due to the Gemfile source cooldown, even though that exact version was already present in Gemfile.lock.

Log excerpt:

Bundler::GemNotFound with message: Could not find gems matching 'net-imap (>= 0.6.4.1)' valid for all resolution platforms (aarch64-linux-musl, arm64-darwin, x86_64-linux) in rubygems repository https://rubygems.org/ or installed locally.

The source contains the following gems matching 'net-imap (>= 0.6.4.1)':
  * net-imap-0.6.4.1

1 version excluded by the cooldown setting; pass `--cooldown 0` to bypass.

net-imap 0.6.4.1 was published on 2026-06-09. The Dependabot run happened on 2026-06-15, so it was inside the Gemfile's cooldown: 10 window. That explains why Bundler considered it too new, but it does not seem like it should have been treated as a new candidate for an unrelated dependency update when the version was already locked.

Native package manager behavior

On the same repository state, normal Bundler install/check behavior succeeds because the locked version is already present:

$ bundle check
The Gemfile's dependencies are satisfied

Local partial update resolution also preserved the locked net-imap version when testing with Bundler 4.0.13:

$ bundle lock --update sentry-ruby sentry-rails sentry-sidekiq --print
...
net-imap (0.6.4.1)
...
net-imap (>= 0.6.4.1)

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

Failing job:

https://github.com/GreatQuestion/great_question/actions/runs/27538704767/job/81394619325

The job may require repository access to view.

Smallest manifest that reproduces the issue

I do not yet have a reduced public reproduction. The suspected shape is:

1. Gemfile has source "https://rubygems.org", cooldown: 10.
2. Gemfile requires a direct dependency whose only satisfying version was published less than 10 days ago.
3. Gemfile.lock already contains that satisfying version.
4. Dependabot runs a Bundler version update for an unrelated dependency.
5. Dependabot/Bundler resolution rejects the already locked non-target dependency due to cooldown.