panics on BrokenPipe error

[dekellum]

With some test of timeout behavior, currently in dekellum/body-image@225a0b2 (branch stub-timeout-tests which may be further rebased), I'm seeing intermittent panics at src/connector.rs:61:40. Its fortunately never panics the test thread (because I'm not using current_thread runtime?), so this more a nuisance than a blocking issue for me.

Finally, note that I have comparable timeout test againsts a real hyper server (see async/tests/server.rs in same repo) where I don't see these panics.

% cargo test ::stub::test_timeout --all-features
    Finished dev [unoptimized + debuginfo] target(s) in 0.12s                                                             
     Running target/debug/deps/body_image-88da9d1ed84cfb3f

running 3 tests
test async::tests::stub::test_timeout_pre ... ok
thread 'tokio-runtime-worker-3' panicked at 'Error { kind: BodyWrite, cause: Some(Custom { kind: BrokenPipe, error: StringError("closed") }) }', /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-stub-0.1.0/src/connector.rs:61:40
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'tokio-runtime-worker-3' panicked at 'Error { kind: BodyWrite, cause: Some(Custom { kind: BrokenPipe, error: StringError("closed") }) }', /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-stub-0.1.0/src/connector.rs:61:40
test async::tests::stub::test_timeout_streaming_race ... ok
test async::tests::stub::test_timeout_streaming ... ok

% # it sometimes succeeds without these
% cargo test ::stub::test_timeout --all-features
    Finished dev [unoptimized + debuginfo] target(s) in 0.11s                                                                                         
     Running target/debug/deps/body_image-88da9d1ed84cfb3f

running 3 tests
test async::tests::stub::test_timeout_pre ... ok
test async::tests::stub::test_timeout_streaming_race ... ok
test async::tests::stub::test_timeout_streaming ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 57 filtered out

[alyssais]

I can reproduce this and will do my best to investigate.

[dekellum]

Here is another possible (intermittent) failure mode for the stub timeout tests:

https://travis-ci.org/dekellum/body-image/jobs/410416615#L663

failures: ---- async::tests::stub::test_timeout_streaming stdout ---- thread 'async::tests::stub::test_timeout_streaming' panicked at 'should have timed-out!', src/async/tests/stub.rs:176:13 note: Run with RUST_BACKTRACE=1 for a backtrace.

FYI: I've adopted a strategy of labeling the less-than 100% tests with a may_fail non-default feature, so I've gone ahead and merged these stub timeout tests to master.