Does this really have to be 10s? I think @alyssawilk is not going to be happy with this. :)

Command: > bazel test test/integration:protocol_integration_test --test_filter="*DrainClose/IPv6_Http2Downstream_HttpUpstream" --test_sharding_strategy=disabled --runs_per_test=10

• 3s drain time: Stats over 10 runs: max = 7.5s, min = 7.3s, avg = 7.4s, dev = 0.1s
• 10s drain time: Stats over 10 runs: max = 7.6s, min = 7.3s, avg = 7.4s, dev = 0.1s

I'm fine with whatever, but doesn't seem to be a big difference. (In the long timeout there'll probably just be more retries but those happen quickly.)

Yeah, while I'm not a fan of long sleeping tests, I don't think this affects test timing.
Offhand I think it would result in a 10s pause if we didn't get a request and send a response (if the drain close kicked in when waiting for a new pipelined request) but when we get a new request we respond with connection close and then close the connection after the delay close (not drain time) timeout.

In cases like this it might be good to actually set it super high so the test would time out if we ever tickled the limit, and comment why it's not going to actually slow the test down.

I don't quite understand your explanation. My understanding was that the probability for drain close might be low, but the test will rapidly send requests until a drain close is hit, so the test duration won't generally be increased. I verified this by adding a retry counter and setting the timeout to 100s, and found that the number of requests sent ranged from 15 to 210. This ultimately happens so quickly that the test time isn't really increased.

I bumped the timeout to 100s and added a comment to explain.