迁移至Active Admin后出现applicationController已移除仍活跃错误
Hey there, let's dig into this error you're hitting after migrating to Active Admin. This issue almost always boils down to class reload conflicts in development—where an old version of your ApplicationController is still referenced by other parts of your app after it's been reloaded. Let's break down the likely causes tied to your setup and how to fix them:
1. Action Cable Connection Dependencies (Triggered by Conversations Controller)
Since the error fires from your Conversations controller, it's a safe bet your Action Cable setup is holding onto an old reference of ApplicationController. Action Cable connections are long-lived, so if your ApplicationCable::Connection class relies on methods from ApplicationController (like current_user), when ApplicationController reloads, the connection still uses the old class instance.
Fix:
Move your authentication logic directly into the Action Cable Connection class instead of relying on ApplicationController:
# app/channels/application_cable/connection.rb module ApplicationCable class Connection < ActionCable::Connection::Base identified_by :current_user def connect self.current_user = find_verified_user end private def find_verified_user # Use cookies directly instead of ApplicationController's methods if verified_user = User.find_by(id: cookies.signed[:user_id]) verified_user else reject_unauthorized_connection end end end end
This way, the connection doesn't depend on ApplicationController at all, eliminating reload conflicts.
2. Active Admin & ApplicationController Overlaps
Active Admin inherits from your ApplicationController by default, which means any callbacks, helpers, or methods you've added there get pulled into Active Admin. If those pieces aren't reload-friendly, they can leave old references hanging.
Fixes:
- Isolate Active Admin's Controller: Create a dedicated base controller for Active Admin instead of using
ApplicationControllerdirectly:
# app/controllers/admin/base_controller.rb class Admin::BaseController < ApplicationController before_action :authenticate_admin_user! # Add only Active Admin-specific logic here end
Then update your Active Admin initializer to use this:
# config/initializers/active_admin.rb config.namespace :admin do |admin| admin.controller do inherit Admin::BaseController end end
- Skip Unneeded Callbacks: If you have
before_actioninApplicationController(likeauthenticate_user!), make sure Active Admin skips it:
# In your Admin::BaseController or directly in Active Admin's initializer skip_before_action :authenticate_user!
3. Devise Modal Registration Changes
Switching Devise registration to a modal likely involved customizing the RegistrationsController. If this controller inherits from ApplicationController and adds new logic, it could create circular dependencies or reload issues when combined with Active Admin.
Fix:
Keep your Devise controller focused and avoid unnecessary ties to ApplicationController:
# app/controllers/users/registrations_controller.rb class Users::RegistrationsController < Devise::RegistrationsController respond_to :html, :js # For modal AJAX handling def create super do |resource| if resource.persisted? # Add modal-specific success logic here end end end # Only override methods needed for the modal—don't pull in extra ApplicationController logic end
Double-check your Devise routes to ensure they're pointing to this custom controller correctly, and no conflicts exist with Active Admin's routes.
4. Quick Development Fixes
- Restart Your Server: Sometimes old class references stick around in development—restarting clears these.
- Tweak Reload Settings: Temporarily disable "reload only on change" in
config/environments/development.rbto see if that resolves it:
config.reload_classes_only_on_change = false
This is a diagnostic step, not a permanent fix, but it can confirm if reload triggers are the root cause.
Final Notes
This error is all about stale class references. By isolating dependencies (Action Cable from ApplicationController, Active Admin from general app logic) and keeping custom controllers focused, you'll eliminate the conflict.
内容的提问来源于stack exchange,提问作者Jason Harder

