I haven't figured out if the failure is caused by a problem with the library or with the test. I do seem to have narrowed it down to only failing when the test is run with multiple threads and allowing all the test to be run. When the test is limited to a single thread, or when the test is run in isolation (cargo test --release --lib test_cache_drop_updates -- --test-threads=4), it seems to pass each time.
cargo test and cargo test --release often, but not always, fails with
failures:
---- cache::test::sync_test::test_cache_drop_updates stdout ----
thread 'cache::test::sync_test::test_cache_drop_updates' panicked at 'assertion failed: c.insert(1, \"0\".to_string(), 10)', src/cache/test.rs:680:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
failures:
cache::test::sync_test::test_cache_drop_updates
but running with cargo test -- --test-threads=1 sees it pass each time. I wonder if other tests that preceded this one are having an affect because when the one test is run in isolation, it always passes too.
If it were determined the test isn't designed for multiple threads, I would suggest creating a .cargo/config.toml with
[env]
RUST_TEST_THREADS = { value = "1" }
I would offer a PR but as I said at the top, I don't know if a real problem is being masked by just running the one test or just running with one thread.
I haven't figured out if the failure is caused by a problem with the library or with the test. I do seem to have narrowed it down to only failing when the test is run with multiple threads and allowing all the test to be run. When the test is limited to a single thread, or when the test is run in isolation (
cargo test --release --lib test_cache_drop_updates -- --test-threads=4), it seems to pass each time.cargo testandcargo test --releaseoften, but not always, fails withbut running with
cargo test -- --test-threads=1sees it pass each time. I wonder if other tests that preceded this one are having an affect because when the one test is run in isolation, it always passes too.If it were determined the test isn't designed for multiple threads, I would suggest creating a
.cargo/config.tomlwithI would offer a PR but as I said at the top, I don't know if a real problem is being masked by just running the one test or just running with one thread.