[jira] [Created] (THRIFT-4663) Request payload is two endpoints concatenated together

["David Wire (JIRA)" <ji...@apache.org>]

David Wire created THRIFT-4663:
----------------------------------

             Summary: Request payload is two endpoints concatenated together
                 Key: THRIFT-4663
                 URL: https://issues.apache.org/jira/browse/THRIFT-4663
             Project: Thrift
          Issue Type: Bug
          Components: JavaScript - Library
    Affects Versions: 0.11.0
         Environment: Python backend

React Javascript frontend
            Reporter: David Wire


Originally encountered as a 500 error received from our server.

Investigating the logs on the server came up with this:
{{02:52:33 _elem152 = iprot.readString().decode('utf-8') if sys.version_info[0] == 2 else iprot.readString()}}
{{02:52:33 File "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py", line 184, in readString}}
{{02:52:33 return binary_to_str(self.readBinary())}}
{{02:52:33 File "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py", line 233, in readBinary}}
{{02:52:33 self._check_string_length(size)}}
{{02:52:33 File "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py", line 47, in _check_string_length}}
{{02:52:33 self._check_length(self.string_length_limit, length)}}
{{02:52:33 File "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py", line 58, in _check_length}}
{{02:52:33 'Negative length: %d' % length)}}
{{02:52:33 thrift.transport.TTransport.TTransportException: Negative length: -2147418111}}

It also turned out that this was hitting a different a different processor than expected.

Upon inspection of the request in the browser client I noticed that the payload was two processors concatenated together, in this particular case 'get_usersget_episodes'. The failure, I believe, is because it's executing the get_users processor and trying to turn get_episodes into the parameters for that processor.

Finally, we realized that we were trying to make get_users request with the user_ids array (one of the parameters) containing only a null element. [null]. This request is never sent and seems to hang out waiting for the next request to be sent.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)