Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Invalid
-
None
-
None
-
None
Description
have a Thrift structure which contains a field "headers" which is a list<...> :
/** A TIDE with sorted TIE headers, if headers unsorted, behavior is undefined */
{{ struct TIDEPacket {}}
{{ /** all 00s marks starts */}}
{{ 1: required TIEID start_range;}}
{{ /** all FFs mark end */}}
{{ 2: required TIEID end_range;}}
{{ /** sorted list of headers */}}
{{ 3: required list<TIEHeader> headers; /* <<<<<< */}}
{{ }}}
This struct is actually deeply nested inside another structure, but that doesn't matter for the bug.
When I encode the message, I pass a Python LIST into the Thrift-compiler generated encoding functions:
... TIREPacket(headers=[TIEHeader(seq_nr=0, origination_lifetime=None, tieid=TIEID(direction=2, tietype=2, originator=2, tie_nr=2), origination_time=None, remaining_lifetime=0)]) ...
Note the square bracket [ after headers=
When I decode that encoded message using the Thrift-compiler generated Python decoding functions, it decodes it as a Python SET instead of a Pythin list:
... TIREPacket(headers={TIEHeader(seq_nr=0, origination_lifetime=None, tieid=TIEID(direction=2, tietype=2, originator=2, tie_nr=2), origination_time=None, remaining_lifetime=0)}) ...
Note the curly bracket { after headers=
Indeed, when I look at the source code of the Python encoding/decoding functions generated by the Thrift compiler, I can see that the list<...> is treated as a SET:
class TIREPacket(object):
{{ """}}
{{ A TIRE packet}}Attributes:
{{ - headers}}
{{ """}}thrift_spec = (
{{ None, # 0}}
{{ (1, TType.SET, 'headers', (TType.STRUCT, (TIEHeader, TIEHeader.thrift_spec), False), None, ), # 1}}
{{ )}}
You might wonder why the code did not crash when I passed a Python list to the encoding function instead of a set.
It is probably because iterating over a list looks exactly the same as iterating over a set.