rx read hangs because of redundant/excessive try_recv()

[gopakumarce]

If self.remaining_data is 0, recv_data() calls poll_next() which will do a try_recv() and bring in and decode the frame. And right after that we end up doing poll_data() which will again do a try_recv and this time it can end up hanging if the other end has not sent any more data. poll_data clearly checks if self.remaining_data is NON-ZERO at the top of that API, so before calling try_recv() it KNOWS that there is data to be read. So even if try_recv() says pending, it can/should go ahead and pull in the existing data.

[seanmonstar]

Thanks! Is this something that would be simple to add a unit test for? Or is it hard to test locally because it's related to buffers and latency?

[gopakumarce]

Thanks! Is this something that would be simple to add a unit test for? Or is it hard to test locally because it's related to buffers and latency?

@seanmonstar it should be UT-able, let me explore the UT ecosystem in h3 and add one for this, will update the PR

[gopakumarce]

Thanks! Is this something that would be simple to add a unit test for? Or is it hard to test locally because it's related to buffers and latency?

@seanmonstar it should be UT-able, let me explore the UT ecosystem in h3 and add one for this, will update the PR

@seanmonstar I have pushed a unit test case for this - I have ensured that the case "hangs" without the fix and works fine post the fix

[seanmonstar]

Excellent work, thanks for catching this and the test so we don't regress in the future!