test: Fix inverted exact match logic in IntegrationTcpClient::waitForData() #4134
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The initial check in IntegrationTcpClient::waitForData() did exact
match check when 'exact_match' parameter was 'false', and an inexact
match when 'exact_match' parameter was 'true'. If the initial test
fails, the forthcoming test in WaitForPayloadReader::onData() was
using the logically correct interpretation of the 'exact_match'
parameter.
This resulted in wait never completing for inexact matches
that should have matched data that was already received. The correct
test in WaitForPayloadReader::onData() would always correctly match
data that is received after IntegrationTcpClient::waitForData() is
called.
Fix the incorrect logic by reuing the logical pattern of
WaitForPayloadReader::onData() also in
IntegrationTcpClient::waitForData(), except for not skipping the exact
match on an empty search string.
Testing: Added a iine in TCP proxy integration test that fails/hangs
without the fix.
Risk Level: Low
Signed-off-by: Jarno Rajahalme jarno@covalent.io