[ https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James E. King III updated THRIFT-4405: -------------------------------------- Description: The following tests were added: * The cpp client for cross test did not use sequence numbers, so I added a testing protocol layer for TestClient on top of all protocols that uses a sequence ID that starts at INT32_MAX - 10, and advances until it wraps around. This caught a number of negative value handling issues. * The cpp client verifies the sequence ID that returns matches what was sent. * The python client was changed to use pedantic sequence ID checking on all protocols. The following errors were identified and fixed: * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other implementations. * In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing; this interacted with a bugfix from 2017 (THRIFT-4138) that dropped boost::lexical_cast and switched to std::stringstream, and this corrupted the negative sequence ID. * In python, compact protocol, a negative sequence ID was not handled properly because it is read in and written out as a "var int" which is always positive. Documentation was added for sequence number handling. was: The following tests were added: * The cpp client for cross test now uses a sequence ID that starts at INT32_MAX - 10, and advances until it wraps around. * The cpp client verifies the sequence ID that returns matches what was sent. * The python client was changed to use pedantic sequence ID checking on all protocols. The following errors were identified and fixed: * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other implementations. * In cpp, JSON protocol, when the server read the header, it used a uint64_t for processing; this interacted with a bugfix from 2017 that dropped boost::lexical_cast and switched to std::stringstream, and this corrupted the negative sequence IDs. * In python, compact protocol, a negative sequence ID was not handled properly. Documentation was added for sequence number handling. > Incorrect handling of sequence numbers that wrap to negative > ------------------------------------------------------------ > > Key: THRIFT-4405 > URL: https://issues.apache.org/jira/browse/THRIFT-4405 > Project: Thrift > Issue Type: Improvement > Components: Test Suite > Affects Versions: 0.11.0 > Environment: docker ubuntu-xenial > Reporter: James E. King III > Assignee: James E. King III > Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The following tests were added: > * The cpp client for cross test did not use sequence numbers, so I added a > testing protocol layer for TestClient on top of all protocols that uses a > sequence ID that starts at INT32_MAX - 10, and advances until it wraps > around. This caught a number of negative value handling issues. > * The cpp client verifies the sequence ID that returns matches what was sent. > * The python client was changed to use pedantic sequence ID checking on all > protocols. > The following errors were identified and fixed: > * In c_glib, thrift_stored_message_protocol was limiting the sequence ID to > [0..G_INTMAX]. This was changed to allow any 32-bit value, matching other > implementations. > * In cpp, JSON protocol, when the server read the header, it used a uint64_t > for processing; this interacted with a bugfix from 2017 (THRIFT-4138) that > dropped boost::lexical_cast and switched to std::stringstream, and this > corrupted the negative sequence ID. > * In python, compact protocol, a negative sequence ID was not handled > properly because it is read in and written out as a "var int" which is always > positive. > Documentation was added for sequence number handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005)