rails: Circular dependency with namespaced concerns
I think I found a bug but I’m not sure if it really is one. I’ve setup a demonstration application here but basically I just have a controller, including a concern, and a runtime error.
class ApplicationController < ActionController::Base
include Fapplication::Authorization
raise "moep"
end
When the controller is being loaded I get the expected raise error. If I refresh the page though I get “Circular dependency detected while autoloading constant Fapplication::Authorization”. This wont change until I resolve the issue (remove the raise). When I then reload the page, the ruby process hangs at 100% CPU and I have to kill it.
This does not happen when the concern isn’t namespaced (include Authorization).
Hope that isn’t filed already, there are a lot of issues with circular dependency warnings…
Cheers!
About this issue
- Original URL
- State: closed
- Created 10 years ago
- Reactions: 1
- Comments: 20 (14 by maintainers)
@dannyyu92 @fxn You are right but it was a workaround. The superclass mismatch has nothing to do with this issue but it’s more a problem of how Ruby works. I now namespace concerns like “UserConcerns::Something” to avoid this superclass mismatch issue (I think there is no other way besides changing the order in how things are loaded).
The classic autoloader is going to start its deprecation cycle with Rails 6.1. This is no longer an issue in
zeitwerkmode because Ruby semantics are matched.In
zeitwerkmode Rails behaves like a regular Ruby program (intentionally). Ruby interprets the file, defines the class, and evaluates its body until it raises. You see an exception in the browser and in consequence you would normally fix it.If nothing is edited, and you continue browsing, the behavior is deterministic: Whatever Ruby does in a case like this is what you’ll see. In particular, a partially defined class if the exception was raised before finishing the body. May be surprising, but that is how Ruby works, and in that situation an exception raised at the top-level was ignored, so a partial class definition is to be expected.
You won’t find circularity warnings or CPUs at 100%.
Since classic is deprecated and in practice unmaintained, I think we can close this one now.
@MrHubble I guess it can but I’m not sure. I worked around this issue and I worked around the superclass mismatch problem. We haven’t yet updated our app to Rails 6 and I can’t really tell what the introduction of Zeitwerk will change about this. I personally haven’t used the Concerns namespace which is what that issue describes or am I missing something?
Moving the concerns out of the concerns directory could still lead to superclass mismatch, can it not? It might just not because it just happens to load them in the right order (I don’t know if it is guaranteed to load in alphabetical order while preloading or if Rails explicitly loads them “outside-in” as in user.rb always loads before user/something.rb but I guess that is how it works). But this wasn’t the original issue anyways.
While model specific concerns should no longer be (or ever been there to begin with) in the concerns subdirectory it still should be put there if it is for multiple models/controllers. I don’t know if the problem would still occur with generic (namespaced) concerns. Honestly I still don’t know what exactly caused the issue and stalling ruby process.
Tbh I’m confused as to how all the issues in this thread are related to each other (superclass mismatch wasn’t the original issue) so I would leave it to the Rails team to close the issue.
If I find some time I will try to provoke the issue with Rails 5 and 6 (with classic and zeitwerk).