On this PR we are finding that PauseOnPollingTentacleSendingNextControlMessage_ShouldNotHangForEver sometimes fails because the port forwarder is observing the NEXT control message is arriving to the port forwarder close enough to the Response message they are considered a single "thing". This confuses the test which relies on finding small packets to know when to pause.
This improves on that rather than make assumption and have deep dependencies on what the code is doing, we (in test only) allow the test to observe when control messages are being sent. This allows the test to pause the port forwarder at exactly the right time without guessing.
This introduces a IControlMessageObserver which allows observation of what is happening with control messages. The halibut builder to set this is marked internal which should prevent surprise uses of this (although if anyone did do this they would probably know what their in for :D )
Using this along with existing byte counting streams we can fix the test by:
Delaying sending of the "NEXT" control message
until we know the client has received all bytes.
An alternative would be to man in the middle ourselves, but then we are just parsing the halibut protocol and depending on how it exactly works, also this becomes tricky since the port forwarder allows pausing on partial SSL frames but if we de-crypted the SSL we wouldn't be able to do that type of pausing.
How to review this PR
Quality :heavy_check_mark:
Pre-requisites
[ ] I have read How we use GitHub Issues for help deciding when and where it's appropriate to make an issue.
[ ] I have considered informing or consulting the right people, according to the ownership map.
[ ] I have considered appropriate testing for my change.
Background
On this PR we are finding that
PauseOnPollingTentacleSendingNextControlMessage_ShouldNotHangForEversometimes fails because the port forwarder is observing the NEXT control message is arriving to the port forwarder close enough to the Response message they are considered a single "thing". This confuses the test which relies on finding small packets to know when to pause.This improves on that rather than make assumption and have deep dependencies on what the code is doing, we (in test only) allow the test to observe when control messages are being sent. This allows the test to pause the port forwarder at exactly the right time without guessing.
This introduces a IControlMessageObserver which allows observation of what is happening with control messages. The halibut builder to set this is marked internal which should prevent surprise uses of this (although if anyone did do this they would probably know what their in for :D )
Using this along with existing byte counting streams we can fix the test by:
An alternative would be to man in the middle ourselves, but then we are just parsing the halibut protocol and depending on how it exactly works, also this becomes tricky since the port forwarder allows pausing on partial SSL frames but if we de-crypted the SSL we wouldn't be able to do that type of pausing.
How to review this PR
Quality :heavy_check_mark:
Pre-requisites