[THRIFT-4663] Request payload is two endpoints concatenated together

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.11.0
• Component/s: JavaScript - Library

Environment

Python backend

React Javascript frontend

• Assignee: Unassigned
• Reporter: David Wire
• Created: 07/Nov/18 22:03
• Updated: 08/Nov/18 17:03

Description

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.

I would expect thrift to send this poorly formed request, with the [null] parameter, to the server where it could generate an exception or for it to generate an exception on the client side that we can track. Having the half-formed request payload sent along with the next request produced an issue which was unnecessarily hard to root cause.

 

Issue Links

• relates to: THRIFT-4564 TBufferedTransport can leave corrupt data in the buffer