exercism
Timeouts on Resistor Color exercise
Some people appear to be experiencing sporadic timeouts on tests for this exercise. Their code appears to be fine locally.
Is that a test-runner issue?
Yes, that's a test runner issue. I believe that there's a max duration hard-coded into the test runner; it may be worth exploring whether it's possible to increase that duration for this exercise at least.
I see. It must be related to exercism/rust-test-runner#30 then. But I can't seem to find the timeout feature anywhere in the code -- so is that somewhere deeper in the infrastructure?
It's likely related to the fact that this specific exercise has external crates.
It's slower than all the other exercises locally and on the test runner. a quick solution might be to have a cached crate ?
I still have same problem. I was advised to leave a comment in the issue if there is one. So here I am. Ready to provide information about my solution, if necessary.
UPD: Tests on the site passed on the fifth attempt.
The dependencies on this exercise were fairly large (~87MB). Depending on network speed, crates.io speed (I average ~20s) and then a non-cached build+test takes ~9s on a local, which I'm guessing is more powerful than the runner. It probably is just luck of the draw on who's will not timeout, or have to run back to back to try and try to hit a build runner who already downloaded the deps. I had timeouts on multiple ~6 tries before I got it to work.
cargo clean ; time cargo test
Updating crates.io index
Downloaded proc-macro2 v1.0.36
Downloaded syn v1.0.86
Downloaded unicode-xid v0.2.2
Downloaded serde v1.0.135
Downloaded enum-iterator-derive v0.7.0
Downloaded proc-macro-crate v0.1.5
Downloaded toml v0.5.8
Downloaded cfg-if v0.1.10
Downloaded int-enum-impl v0.4.0
Downloaded int-enum v0.4.0
Downloaded enum-iterator v0.7.0
Downloaded quote v1.0.15
Downloaded 12 crates (482.1 KB) in 0.44s
Compiling proc-macro2 v1.0.36
Compiling unicode-xid v0.2.2
Compiling syn v1.0.86
Compiling serde v1.0.135
Compiling cfg-if v0.1.10
Compiling quote v1.0.15
Compiling enum-iterator-derive v0.7.0
Compiling toml v0.5.8
Compiling enum-iterator v0.7.0
Compiling proc-macro-crate v0.1.5
Compiling int-enum-impl v0.4.0
Compiling int-enum v0.4.0
Compiling resistor-color v1.0.0 (/Users/gabeio/Exercism/rust/resistor-color)
Finished test [unoptimized + debuginfo] target(s) in 46.92s
Running unittests (target/debug/deps/resistor_color-3539630575024fb4)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Running tests/resistor-color.rs (target/debug/deps/resistor_color-163a2337cede62fa)
running 8 tests
test test_6 ... ok
test test_2 ... ok
test test_11_out_of_range ... ok
test test_8 ... ok
test test_all_colors ... ok
test test_orange ... ok
test test_black ... ok
test test_white ... ok
test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
Doc-tests resistor-color
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
cargo test 44.71s user 5.45s system 105% cpu 47.417 total
not sure why it claims Downloaded 12 crates (482.1 KB) in 0.44s when I recorded the network traffic at 87MB transferred, whatever it was seemed to be a git repo because it also spent time resolving deltas.
This still appears to be an issue. Any progress on this? I cannot submit results either locally or through the web editor. On my local machine, it takes less than 10 seconds.
Having the same issue with this one. It does in fact work sometime, out of sheer luck I believe. The timeout duration might be really close to the average duration of the test. Just curious, isn't there a way to simply manually increase the timeout to this exercise?
The test runner was deactivated for this exact reason. Currently, the learning mode (including this concept exercise) is disabled anyway.
Related: Solving https://github.com/exercism/rust-test-runner/issues/35 could improve build times of exercise solutions with external crates significantly.
