Suppress capturing responses

[gregschohn]

Description

This is the successor to dropping captures for requests. It builds upon some of the refactoring that was done for the instrumentation work.

• Category: Bug fix, Enhancement
• Why these changes are required? To suppress capturing response packets when the requests weren't captured.
• What is the old behavior before changes and new behavior after changes? Spurious response packets would have followed the dropped observation, or if none of the request was present, they could have followed the last request/response, which would have resulted in invalid looking responses from the source cluster (to the point where it could have been impossible to determine what the responses actually were).

Testing

[Please provide details of testing done: unit testing, integration testing and manual testing]

Check List

• New functionality includes testing
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov]

Codecov Report

Attention: 127 lines in your changes are missing coverage. Please review.

Comparison is base (4ee54ef) 73.57% compared to head (7de4009) 74.48%.

Files	Patch %	Lines
...arch/migrations/tracing/SimpleMeteringClosure.java	40.47%	47 Missing and 3 partials ⚠️
...tions/trafficcapture/netty/LoggingHttpHandler.java	84.71%	15 Missing and 9 partials ⚠️
...atahandlers/http/HttpJsonTransformingConsumer.java	72.41%	7 Missing and 1 partial ⚠️
...ions/trafficcapture/tracing/ConnectionContext.java	56.25%	7 Missing ⚠️
...netty/ConditionallyReliableLoggingHttpHandler.java	53.33%	1 Missing and 6 partials ⚠️
...ficcapture/kafkaoffloader/KafkaCaptureFactory.java	84.21%	2 Missing and 4 partials ⚠️
...afficcapture/netty/RequestContextStateMachine.java	0.00%	6 Missing ⚠️
...tions/trafficcapture/proxyserver/CaptureProxy.java	0.00%	3 Missing ⚠️
.../opensearch/migrations/replay/TrafficReplayer.java	66.66%	1 Missing and 2 partials ⚠️
...ure/kafkaoffloader/tracing/KafkaRecordContext.java	90.47%	2 Missing ⚠️
... and 8 more

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #473      +/-   ##
============================================
+ Coverage     73.57%   74.48%   +0.90%     
- Complexity     1181     1271      +90     
============================================
  Files           124      135      +11     
  Lines          4886     5162     +276     
  Branches        439      458      +19     
============================================
+ Hits           3595     3845     +250     
- Misses          996     1010      +14     
- Partials        295      307      +12     

Flag	Coverage Δ
unittests	74.48% <77.64%> (+0.90%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lewijacn]

Trying to understand this... If the state is to ignore response and we have a read we will set to capture. Is that because reads in this case will only be for request packets and we can reset back to capture or is something else happening here?

[gregschohn]

The default assumption is that all requests and their responses will be captured until a request is marked to IGNORE_REQUEST. This is a reset since a new request has begun... and yes, reads are only for requests and writes are only for responses and that's why we now have two states for ignore.