[BUG] 1.15.0 Fiber Support Breaking Cases where fiber not used.

What I tried to do

Use my library as normal

What I expected to happen

It to continue working (given, no breaking change) 1.14.8 -> 1.15.0

What actually happened

2026-06-17 08:31:53  + bundle exec rspec --require rspec_junit_formatter --format RspecJunitFormatter --out .log/junit_rspec.xml
2026-06-17 08:31:53  
2026-06-17 08:31:53  An error occurred while loading spec_helper.
2026-06-17 08:31:53  Failure/Error: require 'provision-common/definition'
2026-06-17 08:31:53  
2026-06-17 08:31:53  NoMethodError:
2026-06-17 08:31:53    undefined method `[]' for Fiber:Class
2026-06-17 08:31:53  
2026-06-17 08:31:53          current = Fiber[:i18n_config] || self.config = I18n::Config.new
2026-06-17 08:31:53                         ^^^^^^^^^^^^^^
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/i18n-1.15.0/lib/i18n.rb:58:in `config'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/i18n-1.15.0/lib/i18n.rb:88:in `load_path'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/i18n.rb:16:in `<top (required)>'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/inflector/inflections.rb:4:in `require'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/inflector/inflections.rb:4:in `<top (required)>'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/inflections.rb:3:in `require'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/inflections.rb:3:in `<top (required)>'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/inflector/methods.rb:3:in `require'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/inflector/methods.rb:3:in `<top (required)>'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/dependencies/autoload.rb:3:in `require'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support/dependencies/autoload.rb:3:in `<top (required)>'
2026-06-17 08:31:53  # ./bundle/ruby/3.1.0/gems/activesupport-7.2.3.1/lib/active_support.rb:27:in `require'
ETC...
2026-06-17 08:31:53  # ./spec/spec_helper.rb:12:in `require'
2026-06-17 08:31:53  # ./spec/spec_helper.rb:12:in `<top (required)>'

Versions of i18n, rails, and anything else you think is necessary

Only i18n 1.15.0

Bonus points for providing an application or a small code example which reproduces the issue.

Thanks! ❤️

same

/home/www-data/.rvm/gems/ruby-3.1.2/gems/i18n-1.15.0/lib/i18n.rb:58:in config': undefined method `[]' for Fiber:Class (NoMethodError)

  current = Fiber[:i18n_config] || self.config = I18n::Config.new
                 ^^^^^^^^^^^^^^
    from /home/www-data/.rvm/gems/ruby-3.1.2/gems/i18n-1.15.0/lib/i18n.rb:88:in `load_path'`

I'm also affected by this. I'm just using active_support

require 'active_support'
require 'active_support/core_ext/object/blank'

This triggers:

/usr/local/bundle/gems/i18n-1.15.0/lib/i18n.rb:58:in `config': undefined method `[]' for Fiber:Class (NoMethodError)

      current = Fiber[:i18n_config] || self.config = I18n::Config.new
                     ^^^^^^^^^^^^^^
	from /usr/local/bundle/gems/i18n-1.15.0/lib/i18n.rb:88:in `load_path'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/i18n.rb:16:in `<top (required)>'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/inflector/inflections.rb:4:in `require'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/inflector/inflections.rb:4:in `<top (required)>'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/inflections.rb:3:in `require'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/inflections.rb:3:in `<top (required)>'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/inflector/methods.rb:3:in `require'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/inflector/methods.rb:3:in `<top (required)>'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/dependencies/autoload.rb:3:in `require'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support/dependencies/autoload.rb:3:in `<top (required)>'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support.rb:27:in `require'
	from /usr/local/bundle/gems/activesupport-7.2.3.1/lib/active_support.rb:27:in `<top (required)>'
	from /usr/local/bundle/gems/dragnet-6.1.0/lib/dragnet/exporters/serializers/test_record_serializer.rb:3:in `require'

I mean, the problem here is switching to Fibers

I think the issue is that the mentioned #731 PR dropped support for Ruby 3.2, but the gemspec was not updated accordingly. I have a CI matrix where only Ruby 3.1 checks failed with this error - older Ruby versions are already unsupported, newer versions have the Fiber storage available

I think the latest version bump (1.15.0) has some inconsistencies:

README say:

--  We support Ruby versions from 3.0 and up.
++ We support Ruby versions from 3.2 and up.

gemspec:

 -- s.required_ruby_version = '>= 2.3.0'
 ++ s.required_ruby_version = '>= 3.1'

matrix github workflow:

  --    ruby_version: [head, 3.4, 3.3, 3.2, jruby]
  ++  ruby_version: [head, 3.4, 3.3, jruby]

Fiber#[] was introduced in ruby 3.2 so the correct change should be all >= 3.2

README OK
gemspec: s.required_ruby_version = '>= 3.2'
ruby_version: [head, 3.4, 3.3, 3.2, jruby]

@kiskoza

If what @kiskoza says is true, could any of the maintainers yank 1.15.0 from Rubygems, please? Since that version says it requires Ruby >= 3.1 Bundler will happily update to or install it under Ruby 3.1.x causing things to break.

Maybe @radar ?

Radar’s been asleep for most of this issue’s lifetime. He’s awake now, but at the gym. Then there’s the rest of the morning’s fluff to get through.

Issue acknowledged, and I’ll fix this when I’m back at my desk later today (eta: 2hrs or so.)

fix #735 NoMethodError: undefined method [] for Fiber:Class

I've released 1.15.1 with this fix.

I believe that 1.15.0 isn't broken "enough" to yank the version. It requires a specific version of Ruby, and one that's EOL'd for about a year now. As such, I will keep 1.15.0 up.

Yanking the gem can cause downstream problems:

I yank the gem
Someone has this fixed in their Gemfile.lock to 1.15.0
A bundle install gets run during a CI run, attempting to install that specific version
The CI breaks because it can't find that gem

But the application would work still even if that version existed.

Fix a build error in the Ruby 3.1 CI matrix

Update `i18n`

Revert "[Tests] Skips jbuilder for specific version of JRuby"

Increase minimum Ruby requirement to 3.2.2

Fix ruby-i18n/i18n#735

I believe that 1.15.0 isn't broken "enough" to yank the version. It requires a specific version of Ruby, and one that's EOL'd for about a year now. As such, I will keep 1.15.0 up.

JRuby 9.4 (which provides compatibility with Ruby 3.1) had a release 9.4.15.0 just 10 days ago (2026-06-08), and this bug surfaces there, too. Although I believe that was intended to be the last release in JRuby's 9.4 series, it's pretty recent and due to the way the graph resolves in bundler, the i18n-1.15.1 mitigation doesn't help (it still resolves 1.15.0 as a matching target when we specify ~> 1, ~> 1.14 etc).

Fix a build error in the Ruby 3.1 CI matrix

@radar

@radar Respectfully, I don't agree with your assessment on yanking. I have a number of gems that support multiple Ruby versions, and Ruby 3.1 is effectively broken because 1.15.0 exists and is what bundle chooses to install. If I constrain my gem to <1.15.0, then I run the risk of things like security issues for those on newer Ruby versions where I want the newer i18n to come in. So, my gems are "stuck". I think a yank of 1.15.0 would be a good thing...anyone with it in their Gemfile.lock is not stuck and have an easy fix to just change to a version they want.

(Apologies for posting on 3 issues 😅 - I didn't realize there were others)

I've opened #739 to restore Ruby 3.1 support, as an alternative to yanking 1.15.0.

#731 started using Fiber[] unconditionally, but that API only exists on Ruby 3.2+. 1.15.1 just bumped required_ruby_version to >= 3.2, so Ruby 3.1 users can't install it and are stuck on the broken 1.15.0.

The PR brings back the Fiber.respond_to?(:[]) guard (thread-local fallback otherwise) and sets required_ruby_version = '>= 3.1'. Once a release includes this, Bundler resolves to that newer version instead of
1.15.0 on Ruby 3.1 (highest eligible version), even with ~> 1, so no < 1.15.0 constraint and no yank needed. This also covers JRuby 9.4 (RUBY_VERSION 3.1.x, no Fiber[]) via the same feature detection.

Unlike applications, libraries provide value by remaining usable for a broad range of users, even when that means supporting older Ruby versions beyond Ruby's own EOL timeline.

Restore Ruby 3.1 support

@Fryguy

@Fryguy @yaauie You can now use v1.15.2, with @koic's great patch. That should solve your problems.

You guys rock! Thank you so much!

Revert "Fix ruby-i18n/i18n#735"

Navigation Menu

Repository navigation

[BUG] 1.15.0 Fiber Support Breaking Cases where fiber not used. #735

What I tried to do

What I expected to happen

What actually happened

Versions of i18n, rails, and anything else you think is necessary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] 1.15.0 Fiber Support Breaking Cases where fiber not used. #735

Description

What I tried to do

What I expected to happen

What actually happened

Versions of i18n, rails, and anything else you think is necessary

Activity

YashaVinter commented on Jun 17, 2026

sergio-bobillier commented on Jun 17, 2026

YashaVinter commented on Jun 17, 2026

kiskoza commented on Jun 17, 2026

oniram88 commented on Jun 17, 2026

sergio-bobillier commented on Jun 17, 2026

radar commented on Jun 17, 2026

radar commented on Jun 17, 2026

yaauie commented on Jun 18, 2026

Fryguy commented on Jun 19, 2026

koic commented on Jun 19, 2026

radar commented on Jun 19, 2026

Fryguy commented on Jun 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions