I'm experiencing a strange error in Rails 3.2 where the thread-local controller variable is different than the current request's controller. Having a hard time tracking it down, but we're using Unicorn (forked processes) and virtually have no threading in our app, so I'm having a hard time figuring it out.
The place where this occurs is when we override append_info_to_payload in ApplicationController (which is used in the action_controller instrumentation). We just append information to the instrumentation payload that references the current user, via Authlogic. Every once in a while, an error will be raised in this overriden method that indicates the Authlogic controller isn't the same as the current one.
My question is: wouldn't it be a good idea to use an after_filter (in Rails adapter, for example) to unset Authlogic::Session::Base.controller after the request to ensure that the var doesn't stick around?
Aha! I figured it out. The rails authenticity token filter is set before activate_authlogic:
[:verify_authenticity_token, :activate_authlogic, ... ]
When the :verify_authenticity_token fails, the controller var is never set in activate_authlogic, so our append_info_to_payload call is referring to the previous request's controller instead. Seems like there could still be some way to prevent this from happening, albeit an edge case.
Integrate request_store to solve threading issues.
See also drapergem/draper#390