In a Rails 6 app, when the config cache_classes is false, I'm not able to unsubscribe global listeners declared in an initializer within another process, such as inside a rake task or through the rails console.
For instance. Given the following code inside config/initializers/listeners.rb file
Wisper.subscribe(FooListener)
If I run the rails console and try to unsubscribe the FooListener from Wisper, it won't work:
Wisper.unsubscribe(FooListener)
Wisper::GlobalListeners.registrations.each {|listener| puts listener.inspect} # Display an entry for FooListener
It works as expected when config.cache_classes is true, though. I've just upgraded an app from Rails 5 to 6.
I did not have faced this problem before upgrading from Rails 5. However, I could not find any significant behavior change in cache_classes behavior that would cause the above problem.
Does anybody have an idea what is going on? Is this a bug in wisper?
In a Rails 6 app, when the config
cache_classes
is false, I'm not able to unsubscribe global listeners declared in an initializer within another process, such as inside a rake task or through the rails console.For instance. Given the following code inside
config/initializers/listeners.rb
fileIf I run the rails console and try to unsubscribe the FooListener from Wisper, it won't work:
It works as expected when config.cache_classes is true, though. I've just upgraded an app from Rails 5 to 6.
I did not have faced this problem before upgrading from Rails 5. However, I could not find any significant behavior change in cache_classes behavior that would cause the above problem.
Does anybody have an idea what is going on? Is this a bug in wisper?
My current configuration: