Photo-1 Photo-2 Photo-3 Photo-4 Photo-5 Photo-6

@brentmc79

@brentmc79

Full-time web developer. Part-time smart ass.

I'm Brent Collier.

After a year and a half as an engineer on Twitter's Trust & Safety team, I'm looking for my next gig. Contact me if you know of something interesting.

#

Raise the roof and stay dry

Posted on 04/21/2010

Recently, I was playing around with a little OAuth consumer app that I had thrown together.  Everything was all fine and dandy until suddenly I began seeing those damned "Something went wrong" Rails error pages.  You know what I'm talking about...

Screen_shot_2010-04-21_at_1.15.52_AM.png

Well, as it turns out, the problem was the sketchy OAuth provider api.  It was down/unresponsive/whatever.  Shame on me for not writing robust enough code to blow up gracefully.

What's a girl to do?  I'm not sure about her, but what I did was come up with a dry little way to not see that stupid red apology again.

All of my OAuth crap was in the same controller, and whenever the oauth gem choked on the sketchy api I just wanted it to redirect back to the referrer.  So here's what I did...

def raises_exception?
      begin
        yield
      rescue => ex
        Rails.logger.info("Exception occurred (#{ex.class.to_s}): #{ex.message}")
        flash[:error] = "There was a problem completing your request.  Please try again later."
        redirect_to request.referrer
        return true
      end
      return false
    end
    

And then anywhere in my controller that I was calling an oauth method that might spawn a request (and bomb), I did this...

return if raises_exception? do
      # call out to the sketchy api
    end
    

So in the raises_exception? method, it yields to block of code inside a rescue block.  If an exception occurs, its rescued, logged, and then the request is redirected back to the referrer.

One thing to take note of -- you have to prepend the raises_exception? call with return if.  Otherwise, the code in that action will continue to execute, and I'm pretty sure you wouldn't want that.

There you have it, just a little sumthin-sumthin...

#

IE7's Accept Header And Rails respond_to Bug

Posted on 10/28/2009

Earlier this afternoon, I was debugging an ajax call that consistently resulted in an error, but only in IE.  Checking the log file, I found this:

Processing ApplicationController#index (for 192.168.1.108 at 2009-10-27 14:37:03) [GET]
Session ID: ddde16cf83baca85a81e9fb0772c2844
Parameters: {"format"=>"js", "page"=>"1"}


ActionController::MethodNotAllowed (Only get, head, post, put, and delete requests are allowed.):
/vendor/rails/actionpack/lib/action_controller/routing/recognition_optimisation.rb:65:in `recognize_path'
/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:384:in `recognize'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:154:in `handle_request'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:107:in `dispatch'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:104:in `synchronize'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:104:in `dispatch'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:120:in `dispatch_cgi'
/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:35:in `dispatch'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/request_handler.rb:50:in `process_request'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_request_handler.rb:207:in `main_loop'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:378:in `start_request_handler'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:336:in `handle_spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb:183:in `safe_fork'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:334:in `handle_spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:163:in `start'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/railz/application_spawner.rb:213:in `start'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:262:in `spawn_rails_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:126:in `lookup_or_add'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:256:in `spawn_rails_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:80:in `synchronize'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server_collection.rb:79:in `synchronize'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:255:in `spawn_rails_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:154:in `spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/spawn_manager.rb:287:in `handle_spawn_application'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `__send__'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:352:in `main_loop'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/lib/phusion_passenger/abstract_server.rb:196:in `start_synchronously'
/Library/Ruby/Gems/1.8/gems/passenger-2.2.5/bin/passenger-spawn-server:61

Rendering /Users/brent/Intridea/project/vendor/rails/actionpack/lib/action_controller/templates/rescues/layout.erb (method_not_allowed)

WTF?  That told me a whole lotta nothing.

First of all, it was blowing up before it even got into the application code, which was was strange because it worked just fine in Firefox, Safari, etc.  Second, I checked the response body and it was returning html.  Html?  The format is clearly specified as "js" in the request parameters.  Double-checking the controller code, there was definitely a respond_to block with format.js, so why was it returning html?

I showed this to one of my coworkers and he asked if I had tried switching the format calls in the respond_to block.  There were two, one for html and one for javascript.  I switched them up, and put the format.js first.  I reloaded the page, and what do you know, it worked!  No error.  Again, wtf?  He told me that this same bug had kicked his ass on a previous project.

Aparently, IE7 isn't specific about what sort of response it expects in the accept header.  This causes Rails to merely return the first format that it comes to.  In my case, the html.

So if you're not seeing the format that you're expecting when testing with IE7, try reordering the format calls in the respond_to block.