Verify SDK can handle blank response and error message for /signature_request/cancel about hellosign-ruby-sdk HOT 17 CLOSED

I get

HelloSign.cancel_signature_request(signature_request_id: "ecde12e7cf213592234e9eccf57d8dd59829958e")
MultiJson::LoadError: 795: unexpected token at ''
from gems/json-1.7.6/lib/json/common.rb:155:in `parse'

I pulled down the repo and put a binding.pry here I got

pry(#<HelloSign::Client>)> response.body
=> "\x1F\x8B\b\x00\x00\x00\x00\x00\x00\x03\xE3\x02\x00\x93\x06\xD72\x01\x00\x00\x00"

When the response is passed to MultiJson.load there is strip called on it which turns that string into "\x1F\x8B\b\x00\x00\x00\x00\x00\x00\x03\xE3\x02\x00\x93\x06\xD72\x01"

I just replicated these as I was typing this up, so it looks like it is still happening.

from hellosign-ruby-sdk.

Heya @parkeryoung -

Are you doing anything special here with the response, or otherwise altering the normal flow of the request?

On my side, I just tried a few cancel requests like this:

client.cancel_signature_request :signature_request_id => '6db6107eae125a3572373352b57928b1fcfcfdff'

And got the correct empty response for the first success case, then an appropriate error for subsequent attempts:

Server responded with code 410 (HelloSign::Error::Gone)
Request URI: https://api.dev-hellosign.com/v3/signature_request/cancel/64b6107eae125a3572373352b57928b1fcfcfdff
Message: 
{
    "error": {
        "error_msg": "This resource has been deleted",
        "error_name": "deleted"
    }
}

Are you doing something different here?

from hellosign-ruby-sdk.

I'm not doing anything different that I'm aware of. I generated the request and cancelled it as shown. The only difference I can see is you are using an instance of the client rather than the class, but that shouldn't make a difference as the class delegates to an instance. I get the correct (error) response on subsequent requests.

I am generating the requests in test_mode. The requests seem to be fine. Looking at the API Dashboard, it looks like the request is successful. Cancel is the only method I have had some kind of issue with. The API is obviously not sending valid JSON back.

Do you have any ideas as to what I might want to look for?

from hellosign-ruby-sdk.

Are your gems up-to-date?

from hellosign-ruby-sdk.

The HelloSign gem was at the time I tested it out, I pulled down this repo and pointed my Gemfile to the local copy. The JSON gem may not be totally up-to-date, but the response isn't JSON to begin with.

from hellosign-ruby-sdk.

Hi @parkeryoung -- sorry for the delay.

I also noticed the difference in the instance vs / singleton way our calling of the lib differs. You're right that it shouldn't make a difference -- could you give a shot at instantiating a client first just to be sure?

I'd just like to cover the bases on this, as I'm not at all able to reproduce what you're seeing.

Alternatively -- if you run the cancel as a cURL command, aka

curl 'https://api.hellosign.com/v3/signature_request/cancel/<sig req id>' \
    -u '<API KEY>' \
    -X POST

does it work?

from hellosign-ruby-sdk.

client.cancel_signature_request signature_request_id: "557492b529f41f45dc8399156a792acff5d8daad"
MultiJson::LoadError: 795: unexpected token at ''
from /Users/pyoung/.rvm/gems/ruby-2.1.1@portals/gems/json-1.7.6/lib/json/common.rb:155:in `parse`

Same issue using the client instance.

curl 'https://api.hellosign.com/v3/signature_request/cancel/ad22bd30b06371a0e95e91c89f4cbf1f5200c86f' \
-u '[REDACTED]' \
-X POST

curl 'https://api.hellosign.com/v3/signature_request/cancel/ad22bd30b06371a0e95e91c89f4cbf1f5200c86f' \
    -u '[REDACTED]' \
    -X POST

{"error":{"error_msg":"This resource has been deleted","error_name":"deleted"}}%

However running the curl command seemed to work fine. Maybe has something to do with how Faraday is parsing the response? We are on faraday (0.8.7) and have a faraday_middleware (~> 0.9) gem, I can try to upgrade faraday and I'll take a look into the faraday_middleware gem. Perhaps there is some kind of incompatibility there?

from hellosign-ruby-sdk.

Upon closer inspection the gem that was depending on faraday_middleware is something we don't use anymore and needed to be removed anyway. I removed it, ran bundle update faraday and have faraday (0.9.1) in my Gemfile.lock now. I started up a new console and ran the test again with the same results.

from hellosign-ruby-sdk.

Thanks for trying that @parkeryoung -- I'm a bit mystified as to how this is happening for you but not for us.

We're not specifying a version of Faraday per se in the Gemspec for this SDK, so the latest should definitely be working, at the very least.

How bout this:

1. Could you send the actual signature request ID you're canceling to [email protected] ? I'd like to take a look at what we've tried to send back to you.
2. When you did that bundle update, it looks like you only updated faraday. Does a general update help at all?
3. Once we get 1) above I'll try to recreate your situation as best I can tomorrow and see if I can make this happen.
4. What version of Ruby are you running (doubt this is an issue, but worth checking)?

from hellosign-ruby-sdk.

All of the IDs I have been posting have been actual signature request IDs. They are test ones, but real ones none the less.

I'm using ruby 2.1.1p76 a little behind, but not too far.

I'll do a general gem update but that could be easier said than done in our app.

from hellosign-ruby-sdk.

OK, gotcha @parkeryoung -- I'll check that out and let you know if I find anything here.

from hellosign-ruby-sdk.

Hmm, nothing out of the ordinary, @parkeryoung . Looks like these should have been pretty standard responses back from the cancel calls that failed for you.

One more thing to try here -
When you instantiate the client, try setting :logging => true, :log_level => Logger::DEBUG

This should allow us to see the headers of what you're getting sent.

I'd be curious if we need to do some kind of extra detection in some cases -- I'm still not able to repro here...

from hellosign-ruby-sdk.

pry(main)> client.cancel_signature_request({signature_request_id: "86a5675963e9283d294a9595d5f09ca1617d71b0"})

post https://api.hellosign.com/v3/signature_request/cancel/86a5675963e9283d294a9595d5f09ca1617d71b0
User-Agent: "hellosign-ruby-sdk/3.2.1"
Authorization: "Basic YzhlNDViZGE2ZjQwMDE4MmU4YzE1NGZkZWYzZDRkNDI5MDQ3ZGE5MWQ4ODY4NzExMjk4MDVlOWFlYmI2ZDFlODo="
Content-Type: "application/x-www-form-urlencoded"
200
access-control-allow-headers: "Authorization, Origin, X-Requested-With, Content-Type, Accept"
access-control-allow-methods: "GET, POST, OPTIONS"
access-control-allow-origin: "*"
content-encoding: "gzip"
content-type: "text/html; charset=utf-8"
date: "Thu, 10 Sep 2015 13:40:53 GMT"
p3p: "CP=\"NOP3PPOLICY\""
server: "Apache"
user-agent: "HelloSign API"
vary: "Accept-Encoding"
x-content-type-options: "nosniff"
x-ratelimit-limit: "500"
x-ratelimit-limit-remaining: "499"
x-ratelimit-reset: "1441892453"
x-xss-protection: "1; mode=block"
content-length: "21"
connection: "Close"
MultiJson::LoadError: 795: unexpected token at ''
from /Users/pyoung/.rvm/gems/ruby-2.1.1@portals/gems/json-1.7.6/lib/json/common.rb:155:in `parse'

Here is the output. My general bundle update failed on something so I haven't been able to run it that way.

from hellosign-ruby-sdk.

Thanks again for that, @parkeryoung .

So, good news and bad news...
TL;DR - we think this is probably due to a middleware issue that's altering the response.

I compared the headers with what I get here, and the only difference is that your headers seem to include content-encoding: "gzip", whereas what I'm seeing does not. (I can post the full headers if you're interested, but they match up pretty exactly).

I'm guessing that some sort of Faraday middleware you have may be altering this as it comes in - this could be verified by using RVM / rubyenv or similar to get a clean Ruby environment and testing. However, there may be an easier way:

Since this response is coming in as content-type 'text/html', we shouldn't be parsing it as JSON anyways.

By switching on that we may be able to get around your issue - could you try monkey patching in the following?

def parse(response)
  if response['content-type'] == 'application/pdf'
    response.body
  elsif response.body.strip.empty?
    {}
  elsif response['content-type'] == 'application/json'
    MultiJson.load response.body.strip
  else
      response.body
  end
end

If it works, we can add it formally to the SDK.

from hellosign-ruby-sdk.

Okay, so the gzip thing did lead me down a road. Apparently we had a problem similar to this one with another 3rd party we were integrating with at some point. We put

#
# http://stackoverflow.com/questions/13397119/ruby-nethttp-not-decoding-gzip/20470115#20470115
#
module HTTPResponseDecodeContentOverride
  def initialize(h,c,m)
    super(h,c,m)
    @decode_content = true
  end
  def body
    res = super
    if self['content-length']
      self['content-length'] = res.bytesize if res.respond_to?(:bytesize)
    end
    res
  end
end
module Net
  class HTTPResponse
    prepend HTTPResponseDecodeContentOverride
  end
end

in an initializer. Our repo has 3 different apps in it that share some code via symlink (please don't judge me, I didn't choose this), this symlink was broken. Adding this in fixes the issue I was having. Still kind of confused as to why it was only that one request.

As for the patch to the SDK, it will no longer raise an exception, however it still doesn't properly parse the response to be empty. The initializer fix will actually cause the response to be able to be parsed properly and will return an empty hash. The result I got was "\x1F\x8B\b\x00\x00\x00\x00\x00\x00\x03\xE3\x02\x00\x93\x06\xD72\x01\x00\x00\x00"
but perhaps these insights will help y'all come to a more permanent fix. If you need any more help testing out fixes for this, feel free to let me know.

Are you running ruby 2.2? Perhaps you can reproduce it in ruby 2.1.x?

Edit - It seems as though this is caused due to right_aws and right_http_connection.

from hellosign-ruby-sdk.

Hey @parkeryoung,

Huh, hadn't seen that before, but per that Stack Overflow question linked in there it does seem to be linked to gzip unencoding as well.

Glad you got it sorted -- I'm still certain we're not sending that gzip header from our side, however, so that's likely to still be middleware of some sort. Just looked up right_http_connection -- seems like a likely candidate for where this might be coming from indeed. Are you guys using that gem?

Re: versions -- we tested this yesterday with v.2.0.0 and v2.2.x of Ruby and we couldn't get it to repro on either.

I think it's probably reasonable to put in the extra check for application/json so we don't bomb, but we probably will want to leave the system http modules alone for now.

I'll create an issue for the former.

Thanks for your patience on this, and stoked that it'w working for you now.

from hellosign-ruby-sdk.

Yes we are using right_aws. I think we have planned on pulling it out at some point, but I don't know exactly how much it is used in our app.

from hellosign-ruby-sdk.