Skip to content

Defining cooldown on the same source as global and as a block, will ignore the block cooldown setting #9723

Description

@dombesz

Describe the problem as clearly as you can

One can have its own gems published on rubygems.org and referenced in a Gemfile. In this case one might prefer to have a 0 cooldown setting for owned gems vs other published gems. In order to achieve this, I tried using a source block for owned gems with a cooldown 0, however the cooldown is being ignored and the global cooldown is used instead, which is incorrect.

In this case, the cooldown 0 for our own gems is ignored and a cooldown of 7 days is applied on them as well.

According to https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html , mixing sources should work, however I believe the cooldown setting is buggy when multiple source definitions are pointing to the same source url.

Did you try upgrading rubygems & bundler?

Yes

Post steps to reproduce the problem

Let's consider the following Gemfile definition:

#Gemfile
source "https://rubygems.org", cooldown: 7

# Set cooldown 0 for our own gems
source "https://rubygems.org", cooldown: 0 do
  gem "my-own-gem", "~>1.1.1"
end

In the example above, cooldown 0 is ignored for "my-own-gem" and cooldown 7 is applied instead. This looks like a bug, because the cooldown configuration of the block should take priority over the global cooldown settings.

Which command did you run?

bundle install

What were you expecting to happen?

The expected result is to have cooldown 0 for gems defined inside source block.

What happened instead?

A cooldown of 7 days is applied even for gems inside the custom source block definition.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions