Skip to content

Conversation

@nikushi
Copy link

@nikushi nikushi commented Nov 30, 2018

Hi, recently I got NoMethodError exception during Marketo side system trouble. This exception happened on GET /identity/oauth/token due to following backtrace.

got #<NoMethodError: undefined method `fetch' for String> with backtrace:
             # ./lib/mrkt/concerns/authentication.rb:34:in `block in authenticate'
             # ./lib/mrkt/concerns/authentication.rb:31:in `tap'
             # ./lib/mrkt/concerns/authentication.rb:31:in `authenticate'

This is a bug of mrkt gem of edge case handling. There is a case that Marketo's server could respond with non json content-type e.g. text/plain. Although I could not confirm what it's content type was accurately, I believe that the exception was caused by the content type, from the stracktrace we got. You can see the detail in the first commit to reproduce the bug.

Failures:

  1) Mrkt::Authentication#authenticate on a unexpected non json response should raise an Error
     Failure/Error: expect { subject }.to raise_error(Mrkt::Errors::Error)

       expected Mrkt::Errors::Unknown, got #<NoMethodError: undefined method `fetch' for "something wrong":String> with backtrace:
         # ./lib/mrkt/concerns/authentication.rb:34:in `block in authenticate'
         # ./lib/mrkt/concerns/authentication.rb:31:in `tap'
         # ./lib/mrkt/concerns/authentication.rb:31:in `authenticate'
         # ./spec/concerns/authentication_spec.rb:5:in `block (3 levels) in <top (required)>'
         # ./spec/concerns/authentication_spec.rb:22:in `block (5 levels) in <top (required)>'
         # ./spec/concerns/authentication_spec.rb:22:in `block (4 levels) in <top (required)>'
     # ./spec/concerns/authentication_spec.rb:22:in `block (4 levels) in <top (required)>'
Copy link
Owner

@raszi raszi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice PR but I don't really know how we should handle this issue. I believe the client should not expect anything but JSON in the response and it should fail early.

Co-Authored-By: nikushi <deneb.ge@gmail.com>
@nikushi
Copy link
Author

nikushi commented Dec 3, 2018

Thanks for reviewing. Do you mean that the middleware I added should not pass 2XX response? Instead it should raise the same error too? I was worried about that point actually. If we choose more strict approach, it should be raised if the middleware see a response type other than json, even if it's status is 2XX or something successful one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants