I really wanted to see what the Rails app was sending back to the phone so I could better identify the issue instead of guessing, so I had a couple ideas:
- See the logs on the phone
- Add something to the rails app to log the error
- Change Rails' BadRequest error class to output the response body
- Monkeypatch the devise_oauth2_providable gem to output the body
Non-StarterThe first option wasn't really feasible because the error wasn't registering as an exception, and therefore not getting caught by Flurry. Second, it's a pain to extract the application logs from the phone itself, especially if it's from a user.
Failed AttemptThe second option looked more probable because we could update the server code much faster than pushing a new iOS version to Apple; however, I wasn't too sure where to start when it came to digging into Rails or the gem.
My first hunch was to try to add a #puts to ActionController or some other class involved in the HTTP request, but this would have to be pretty deep into the Rails code and would need to check the status of each request.
Next, I actually tried to overwrite ActiveResource::BadRequest to kick out the response body; however it wasn't showing up in my tests, so I started to think that these 400 errors weren't being thrown by the core Rails app.
My SolutionMy next clue came from the integration tests for devise_oauth2_providable, which showed the gem returning 400 for several different parameter issues, each with a different message sent in the response body. So in order to dump the response to the logs, I patched in a single method into the gem's error handling code and added it to a file in the Rails initializer directory.
It may not be particularly pretty, but this now gives us insight into the causes of our 400 errors, which we can use to fix up the iOS app and improve our user experience.