Yang Chi 403562276b Remove InvalidConnectionId test ...

Summary:
This test tries to construct a bad packet by using server CID as the
dest CID in a server to client packet. It hopes to verify client will fail
parsing and throw. It used to work fine.

Then a couple month ago, our client code switched to use 0-len client CID. Now
client always read 0 bytes out as Dest CID on received packet. But in this test
case server writes a >0 len CID into the packet as Dest CID since the test case
tries to construct a bad packet. Then client treats these bytes as frame bytes
since it assumes 0 len DestCID. Then it parse frames from there. Now sometimes
parsing fails and we throw from parsing. Sometimes parsing accidentally goes
through, then we may or may not throwing when we process the parsed frames.
For example, if we parse out a stream frame successfully with a local stream ID
that's not open, we throw from there. But sometimes, nothing gets throw, since
we can potentially, for example, parse out a stream frame with a remote stream
ID and just simply create it. Sometime the test just hangs, since the stream ID
is huge and we create thousands of streams.

It's hard to fix this test case and keep it unflaky. For example, I figured by
using (0, 5, 3) instead of (0, 0, 0) as the CID encoding params, the test always
passes. That's because the server generates a CID that will definitely fail
parsing on client side. But if some day draft changes the frame type ID values
again, the test will fail again. And someone else will have to go through this
debugging process all over again.

I think we can just remove this test case altogether.

Reviewed By: mjoras

Differential Revision: D19268239

fbshipit-source-id: 66930d6e9044c863a26e29be1dbad683abc6c96c

2020-01-03 10:52:24 -08:00

195 KiB

Raw Blame History

View Raw