This should fix#3576 (ran it many times locally but only time will tell). The test actually only checked for the opcode of the error. From the name of the test we actually want to test if we see a timeout after a pre-defined time.
## Commits:
* increase readWrite timeout as it is also used in the `Accept` of the tcp
listener:
- before this caused the readWriteTimeout to kick in (rarely) while Accept
- as a side-effect: remove obsolete time.Sleep: in both listener cases
the Accept will only return after successfully accepting and the timeout
that is supposed to be tested here will be triggered because there is a
read without a write
- see if we actually run into a timeout error (the whole purpose of
this test AFAIU)
Signed-off-by: Ismail Khoffi <Ismail.Khoffi@gmail.com>
* makee local test-vars `const`
Signed-off-by: Ismail Khoffi <Ismail.Khoffi@gmail.com>
## Additional comments:
@xla: Confusing how an accept could take longer than that, but assuming a noisy environment full of little docker whales will be slower than what 50 years of silicon are capable of. The only thing I'd be vary of is that we mask structural issues with the code by just bumping the timeout, if we are sensitive towards that it warrants invesigation, but again this might only be true in the environment our CI runs in.