Running gzip_filter_integration_test slowly makes it assert-fail #4474
Description
Description:
If you try to single-step slowly through the gzip integration test, several different varieties of assertion-failures will occur, stemming from real-time timers. In particular, setting a breakpoint in
HttpIntegrationTest::waitForNextUpstreamRequestand slowly single-stepping a few times triggers at least one of the asserts.
This can be resolved by switching to simulated time, but I am concerned this is also an indication that slow machines may cause Envoy to crash, or whether this is a property just of the integration test framework. I plan to issue a PR to switch that test to simulated time, but am wary of hiding a bug.
Example assertions:
[2018-09-19 23:42:15.579][101261][critical][assert] ./test/integration/fake_upstream.h:319] assert failure: parented_ || allow_unexpected_disconnects_. Details: An queued upstream connection was torn down without being associated with a fake connection. Either manage the connection via waitForRawConnection() or waitForHttpConnection(), or set_allow_unexpected_disconnects(true).
See https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md#unparented-upstream-connections
[2018-09-19 18:31:25.835][214389][critical][assert] test/integration/http_integration.cc:264] assert failure: result. Details: The connection disconnected unexpectedly, and allow_unexpected_disconnects_ is false.
See https://github.com/envoyproxy/envoy/blob/master/test/integration/README.md#unexpected-disconnects
Both of these linked comments are about cleanup order, and do not mention anything about real-time sensitivities. Also:
[2018-09-19 18:06:29.435][183320][critical][assert] test/integration/http_integration.cc:269] assert failure: result. Details: Timed out waiting for new stream.
The fake_upstream.h assertion happens in a clean client. It's possible that the other two asserts may have been exposed by messing around with timeout constants in the code.