This project is archived and is in readonly mode.
caches_action breaks with Rack error on redirects
Reported by Stephen Eley | September 8th, 2010 @ 10:09 PM
The relevant parts of my controller in a nutshell (on Rails 3.0, Ruby 1.9.2):
class SessionsController < ApplicationController
caches_action :index, cache_path: ->(c) {c.params}
def index
# Do stuff to load the @sessions variable based on passed parameters
# ...
unless @sessions
redirect_to sessions_path, alert: "Sorry, your search failed. Please try again." and return
end
end
end
This works great so long as the action succeeds. But in the event of a redirect, I get this:
Started GET "/sessions?utf8=%E2%9C%93&type=all&terms=piedmont&scope=both" for 127.0.0.1 at 2010-09-08 15:07:16 -0400
Processing by SessionsController#index as HTML
Parameters: {"utf8"=>"✓", "type"=>"all", "terms"=>"piedmont", "scope"=>"both"}
Read fragment views/localhost:3000/sessions?utf8=✓&type=all&terms=piedmont&scope=both (0.7ms)
Redirected to http://localhost:3000/sessions
Completed 302 Found in 31ms
[2010-09-08 15:07:17] ERROR NoMethodError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.each
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/gems/1.9.1/gems/actionpack-3.0.0/lib/action_dispatch/http/response.rb:155:in `each'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/gems/1.9.1/gems/actionpack-3.0.0/lib/action_dispatch/http/response.rb:102:in `body'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/gems/1.9.1/gems/rack-1.2.1/lib/rack/response.rb:102:in `close'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/gems/1.9.1/gems/rack-1.2.1/lib/rack/handler/webrick.rb:68:in `ensure in service'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/gems/1.9.1/gems/rack-1.2.1/lib/rack/handler/webrick.rb:68:in `service'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
^C^C[2010-09-08 15:08:22] ERROR NoMethodError: undefined method `shutdown' for nil:NilClass
/usr/local/Cellar/ruby/1.9.2-p0/lib/ruby/gems/1.9.1/gems/activesupport-3.0.0/lib/active_support/whiny_nil.rb:48:in `method_missing'
I've confirmed, FWIW, that Webrick is not the problem. I get similar errors in Thin and Unicorn. Operating theory for now is that something in the 'after' filter on the caching is ignoring the fact that a non-200 status was passed, and triggering the standard processing for a response with a body. Will investigate more later, and present a test if I can, but this seemed significant enough that I wanted to report the issue right away.
Comments and changes to this ticket
-
mdrozdziel October 30th, 2010 @ 03:47 PM
Same happens here. Rails 3.0.1, ree 1.8.7. Redirect from a cached_action is causing exact same error.
-
Neeraj Singh November 11th, 2010 @ 07:02 PM
- Assigned user set to Santiago Pastorino
- Importance changed from to Low
I am able to reproduce the mentioned problem but , I think, this is expected.
If you are going to cache an action then that action should not do a redirect. You can easily take the code out to a filter and do any redirection in that filter.
-
Santiago Pastorino November 11th, 2010 @ 10:07 PM
- State changed from new to invalid
As Neeraj if you want to cache you shouldn't redirect after that.
-
mdrozdziel November 12th, 2010 @ 04:05 AM
Regardless if this is expected, I don't think, this misleading and unintuitive error message is a good thing.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
People watching this ticket
Referenced by
- 6480 Action cache filter code incorrectly renders nil response body if response is non-cacheable +1 from me too. This bug causes the issues raised in #577...