Grin: test_start_api often fail on Linux

[garyyu]

I find the Travis-CI test often fail on test_start_api in api folder.

And I test it on macos, repeat a lot of times, always OK.

And I test it on a remote Linux host, it seems always fail.

test test_start_api ... thread 'test_start_api' panicked at 'called `Result::unwrap()` on an `Err` value: Error { inner: 

Request error: Cannot make request: an error occurred trying to connect: Connection refused (os error 111) }', libcore/result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.
FAILED

If enable the backtrace:

test test_start_api ... thread 'test_start_api' panicked at 'called `Result::unwrap()` on an `Err` value: Error { inner: stack backtrace:
   0:     0x5621a1afbf0c - backtrace::backtrace::trace::haeeda11cb0a18d0d
   1:     0x5621a1afa722 - backtrace::capture::Backtrace::new_unresolved::h45cbed6eac10aa2d
   2:     0x5621a1afa2cf - failure::backtrace::internal::InternalBacktrace::new::h445df7993039f59b
   3:     0x5621a1af9f11 - <failure::backtrace::Backtrace as core::default::Default>::default::h2203c1831f1a48a6
   4:     0x5621a1af9f48 - failure::backtrace::Backtrace::new::he894fec3894f8676
   5:     0x5621a1907ce6 - <futures::future::map_err::MapErr<A, F> as futures::future::Future>::poll::h205507627f5818d6
   6:     0x5621a19765b4 - <futures::future::chain::Chain<A, B, C>>::poll::h5d0289f9c19ec313
   7:     0x5621a197d598 - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::hc9f7385ce044d178
   8:     0x5621a1979682 - <futures::future::chain::Chain<A, B, C>>::poll::h9b7129c977f5c6e0
   9:     0x5621a1a70f0f - futures::task_impl::std::set::h72d413974fa41124
  10:     0x5621a1a73f31 - std::panicking::try::do_call::h359e673080048b2f
  11:     0x5621a1b353b9 - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:105
  12:     0x5621a1a72dc9 - tokio_threadpool::task::Task::run::h7571e4ecc1c3e088
  13:     0x5621a1a6c065 - tokio_threadpool::worker::Worker::run_task::h958c4a1d1b7159d2
  14:     0x5621a1a6b15f - tokio_threadpool::worker::Worker::run::h82b944c2a50cee34
  15:     0x5621a1a51f21 - <std::thread::local::LocalKey<T>>::with::h8f40843675170a28
  16:     0x5621a1a51d82 - <std::thread::local::LocalKey<T>>::with::h35dbc8c620a9af6c
  17:     0x5621a1a52228 - <std::thread::local::LocalKey<T>>::with::hc5d33f8ca6b1e5f6
  18:     0x5621a1a54fc7 - tokio::runtime::builder::Builder::build::{{closure}}::h59e1d5790d34a70b
  19:     0x5621a1a7212c - <std::thread::local::LocalKey<T>>::with::h77ec7e80810cf750
  20:     0x5621a1a7227a - <std::thread::local::LocalKey<T>>::with::hf9d21d888eb1caf1
  21:     0x5621a1a747a1 - std::sys_common::backtrace::__rust_begin_short_backtrace::h673d04f6a68e1a27
  22:     0x5621a1a73e8b - std::panicking::try::do_call::h1ca2762add9f1d3d
  23:     0x5621a1b353b9 - __rust_maybe_catch_panic
                        at libpanic_unwind/lib.rs:105
  24:     0x5621a1a6f27c - <F as alloc::boxed::FnBox<A>>::call_box::h2a94c63cedc708d4
  25:     0x5621a1b1312a - <alloc::boxed::Box<alloc::boxed::FnBox<A, Output=R> + 'a> as core::ops::function::FnOnce<A>>::call_once::h75e539106a648d39
                        at /checkout/src/liballoc/boxed.rs:650
                         - std::sys_common::thread::start_thread::h88a639c99862a9f5
                        at libstd/sys_common/thread.rs:24
  26:     0x5621a1b16025 - std::sys::unix::thread::Thread::new::thread_start::h7d7a420a78cfa84d
                        at libstd/sys/unix/thread.rs:90
  27:     0x7f190e8f0493 - start_thread
  28:     0x7f190e41bace - __clone
  29:                0x0 - <unknown>

Request error: Cannot make request: an error occurred trying to connect: Connection refused (os error 111) }', libcore/result.rs:945:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:511
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:426
   6: rust_begin_unwind
             at libstd/panicking.rs:337
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:92
   8: core::result::unwrap_failed
   9: rest::test_start_api
  10: <F as alloc::boxed::FnBox<A>>::call_box
             at libtest/lib.rs:1451
             at /checkout/src/libcore/ops/function.rs:223
             at /checkout/src/liballoc/boxed.rs:640
  11: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105
FAILED

Who can help to fix this?

[garyyu]

To reproduce this test failure:

cd api
cargo test --release test_start_api -- --nocapture

[hashmap]

I can check Friday evening

[sesam]

I tried the repro steps on linux (once) and did NOT reproduce, FWIW.

[garyyu]

As reference, recent Travis-CI failure:

• https://travis-ci.org/mimblewimble/grin/builds/440112917
• https://travis-ci.org/mimblewimble/grin/builds/440094697
• https://travis-ci.org/mimblewimble/grin/builds/440036517

All because of this issue.

[hashmap]

No lack in reproducing it so far, perhaps server is too slow to start in travis

[garyyu]

Copy from https://github.com/mimblewimble/grin/pull/1740#issuecomment-429673899

@hashmap I have to disable part of this test as I said in #1739
Temporarily switch off part of test of test_start_api because of bug: #1722
To avoid Travis-CI failure on this known bug.

1722 still need help for a fix solution.

https://travis-ci.org/mimblewimble/grin/jobs/441261628
https://travis-ci.org/mimblewimble/grin/jobs/441219596
https://travis-ci.org/mimblewimble/grin/jobs/441203547

...

And in my Linux environment (Google cloud host), it's 99% to get fail for test cargo test --release test_start_api.

And I'm sorry I don't know much in this API part and have no idea how to fix this test problem.

I also pasted some backtrace above, the problem is in the unwrap() of Line 74:

    let index = api::client::get::<Vec<String>>(url.as_str(), None).unwrap();

Appreciate to give a true fix on this test 😄

[garyyu]

Closed by #1757