Bug #22263: NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to c59c4d717a)

• Status: Open
• Assignee: -
• Target version: -
• ruby -v: ruby 4.1.0dev (2026-08-25T14:03:04Z master 17026737cc) +PRISM [x86_64-linux]
• Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN

[yahonda (Yasuo Honda)]

1. First occurrence in Rails CI

https://buildkite.com/rails/rails-nightly/builds/4651#01a016ac-eaf9-4a71-9fb6-1924c8a7b9af
(job "activemodel (master-debug)", 2026-08-18, ruby 4.1.0dev (2026-08-18T13:12:35Z master 6b719acc57) +PRISM [x86_64-linux])

Two Active Model tests ran a short-lived Ractor in the test process. A few seconds later, RailtieTest forked child processes (Active Support's fork-based test isolation), and the children failed while booting a Rails application.

2. Steps to reproduce

A Rails checkout is required. Verified with Rails main 0f36bbf72c and the rubylang/ruby:master Docker image (ruby 4.1.0dev (2026-08-25T07:50:12Z master 753ace46fe)); it reproduces every run.

$ git clone https://github.com/rails/rails && cd rails && bundle install
$ cd activemodel
$ bundle exec ruby -w -Ilib:test bin/test test/cases/naming_test.rb test/cases/railtie_test.rb

3. Expected behavior

The forked child behaves like its parent: the Rails application boots and the child exits with status 0 (child: #<Process::Status: pid NNN exit 0>). The test pair reports 0 errors.

4. Actual behavior

The forked child raises an exception during require and exits with status 1; the parent process is unaffected:

$ bundle exec ruby -w -Ilib:test bin/test test/cases/naming_test.rb test/cases/railtie_test.rb
Source locally installed gems is ignoring #<Bundler::StubSpecification name=psych version=5.5.0 platform=ruby> because it is missing extensions
Source locally installed gems is ignoring #<Bundler::StubSpecification name=prism version=1.9.0 platform=ruby> because it is missing extensions
Source locally installed gems is ignoring #<Bundler::StubSpecification name=io-console version=0.8.2 platform=ruby> because it is missing extensions
Source locally installed gems is ignoring #<Bundler::StubSpecification name=io-console version=0.9.2 platform=ruby> because it is missing extensions
Source locally installed gems is ignoring #<Bundler::StubSpecification name=erb version=6.0.7 platform=ruby> because it is missing extensions
Source locally installed gems is ignoring #<Bundler::StubSpecification name=date version=3.5.1 platform=ruby> because it is missing extensions
Run options: --seed 20598

# Running:

............................................................E

Error:
RailtieTest#test_i18n_customize_full_message_defaults_to_false:
NoMethodError: super: no superclass method 'require' for main
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require'
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config'
    test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup'
    test/cases/railtie_test.rb:15:in 'Class#initialize'
    test/cases/railtie_test.rb:15:in 'Class#new'
    test/cases/railtie_test.rb:15:in 'RailtieTest#setup'


bin/test test/cases/railtie_test.rb:36

E

Error:
RailtieTest#test_secure_password_min_cost_is_false_in_the_development_environment:
NoMethodError: super: no superclass method 'require' for main
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require'
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config'
    test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup'
    test/cases/railtie_test.rb:15:in 'Class#initialize'
    test/cases/railtie_test.rb:15:in 'Class#new'
    test/cases/railtie_test.rb:15:in 'RailtieTest#setup'


bin/test test/cases/railtie_test.rb:22

E

Error:
RailtieTest#test_i18n_customize_full_message_can_be_disabled:
NoMethodError: super: no superclass method 'require' for main
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require'
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config'
    test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup'
    test/cases/railtie_test.rb:15:in 'Class#initialize'
    test/cases/railtie_test.rb:15:in 'Class#new'
    test/cases/railtie_test.rb:15:in 'RailtieTest#setup'


bin/test test/cases/railtie_test.rb:42

E

Error:
RailtieTest#test_secure_password_min_cost_is_true_in_the_test_environment:
NoMethodError: super: no superclass method 'require' for main
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require'
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config'
    test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup'
    test/cases/railtie_test.rb:15:in 'Class#initialize'
    test/cases/railtie_test.rb:15:in 'Class#new'
    test/cases/railtie_test.rb:15:in 'RailtieTest#setup'


bin/test test/cases/railtie_test.rb:29

E

Error:
RailtieTest#test_i18n_customize_full_message_can_be_enabled:
NoMethodError: super: no superclass method 'require' for main
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'require'
    /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/gems/4.1.0+4/gems/zeitwerk-2.8.3/lib/zeitwerk/core_ext/kernel.rb:34:in 'Kernel#require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'require'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/application.rb:484:in 'Rails::Application#config'
    /home/yahonda/src/github.com/rails/rails/railties/lib/rails/railtie.rb:148:in 'Rails::Railtie.config'
    test/cases/railtie_test.rb:16:in 'block in RailtieTest#setup'
    test/cases/railtie_test.rb:15:in 'Class#initialize'
    test/cases/railtie_test.rb:15:in 'Class#new'
    test/cases/railtie_test.rb:15:in 'RailtieTest#setup'


bin/test test/cases/railtie_test.rb:49



Finished in 0.088916s, 731.0243 runs/s, 820.9965 assertions/s.
65 runs, 73 assertions, 0 failures, 5 errors, 0 skips
$

5. Bisect result

c59c4d717a2e687972341eab1574196e97d7d7be introduces this behavior.

[yahonda (Yasuo Honda)]

Correction on the bisect result. 98f0921f2b is where the forked RailtieTest children start to crash (SIGSEGV or ArgumentError), not where this NoMethodError starts. Bisecting for the NoMethodError itself, with the same bin/test command, gives:

c59c4d717a2e687972341eab1574196e97d7d7be is the first bad commit
Fix stale super cache on prepend after include

From c59c4d717a on, the five RailtieTest children raise the NoMethodError in every run; at its parent e1fcca5c11 they crash instead. Still reproduces on master 89699e814e (2026-08-25).

[yahonda (Yasuo Honda)]

• Subject changed from Subject: NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to 98f0921f2b) to NoMethodError: super: no superclass method 'require' for main — raised in a forked child process after a Ractor has exited in the parent (bisected to c59c4d717a)

[yahonda (Yasuo Honda)]

• Description updated (diff)

[luke-gru (Luke Gruber)]

I have a reproduction showing the issue:

module M
  def foo
    print "M#foo(orig)"
  end
end
class C; include M; end
M.prepend(Module.new do
  def foo
    print "P#foo("
    super
    print ")"
  end
end)
C.new.foo                          # prime the super cache through the backfilled origin iclass
puts
puts "after primed cache"
module M                           # zeitwerk wraps `require` with an alias
  alias_method :old_foo, :foo      # captures the *prepended* P#foo instead of original M#foo
  def foo
    print "M#foo("
    old_foo
    print ")"
  end
end
puts C.new.foo

Before c59c4d717a2e687972341eab1574196e97d7d7be, we get:

P#foo(M#foo(orig))
after primed cache
P#foo(M#foo(orig)) // clearly wrong, the super cache in P#foo was never cleared so it didn't do a new lookup

After c59c4d717a2e687972341eab1574196e97d7d7be:

P#foo(M#foo(orig))
after primed cache
P#foo(M#foo(P#foo(../ruby/test.rb:10:in 'foo': super: no superclass method 'foo' for an instance of C (NoMethodError)
	from ../ruby/test.rb:21:in 'M#foo'
	from ../ruby/test.rb:10:in 'foo'
	from ../ruby/test.rb:25:in '<main>'

Now instead of ignoring the new M#foo, it does a new lookup. However, because the alias in M#foo captured P#foo instead of M's original M#foo, we get an error. This is confusing behavior to me, and I would expect the lookup from M#foo to not go through P, as P shouldn't be an ancestor of M. However, I'm not sure it is a bug as this behavior may be intentional. With the way it currently works though, Module#prepend doesn't play well with aliasing when you alias from the module you prepended to. I'll work around this by not prepending the RactorRequire module to Kernel when we create a Ractor, as this doesn't interact well with Zeitwerk and Rubygems that alias require.

@jeremyevans0 (Jeremy Evans) is this intentional or a bug?

[jeremyevans0 (Jeremy Evans)]

luke-gru (Luke Gruber) wrote in #note-4:

@jeremyevans0 (Jeremy Evans) is this intentional or a bug?

This is general question of how aliased methods should work with prepend. Currently, we allow a class to alias a method in a module prepended to it:

module M
  def m = 1
end
class C
  prepend M
  alias m2 m
end
C.new.m2
# => 1

I think this is a design mistake. I think that conceptually, you should only be able to alias ancestor methods (same position or later in the lookup chain), and this allows aliasing a descendant method (earlier in the lookup chain). The ancestor chain in this case (in order of method lookup):

C.new.singleton_class
M
C
Object
Kernel
BasicObject

I think in this case, C should only be allowed to alias methods of C, Object, Kernel, and BasicObject. I think the alias m2 m in the above example should be changed to raise NameError.

[jhawthorn (John Hawthorn)]

• Related to Bug #22273: Aliasing doesn't interact well with Module#prepend added

[eightbitraptor (Matt V-H)]

I've just encountered this issue with the following repro:

Ractor.new { 1 }.value
Kernel.module_eval { alias old_require require }
old_require 'tempfile'

Thanks @luke-gru (Luke Gruber) for pointing this ticket out to me.

I ended up patching it to match the existing semantics by making super start from after the prepended module rather than after the alias, but it sounds to me that @jeremyevans0 (Jeremy Evans) doesn't think that's the current semantics are correct.

If we decide that this is a design mistake and change it for Ruby 4.1 what does the blast radius look like? How many gems and other projects are likely to be affected?

Is this something that we want to patch now, but deprecate this release and fix properly for 4.2?