Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Flaky tests: disputes, orders and relay-blacklist tests fail under the full parallel cargo test run

Open
  • Is something wrong?
#439 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust, sqlite
Domain
databases, testing

Research direction

Start with the three named tests in src/api/disputes.rs and src/api/orders.rs, then inspect the relay-blacklist test and the shared state they read or mutate. Run the provided loop from rust to reproduce failures under parallel test execution, and compare with each test run alone. Done means the full repeated cargo test --lib runs pass reliably.

Written by the indexing model from the issue text.

Description

area: rust-core bug tests

What happens

cargo test --lib fails intermittently on tests that pass when run alone, and a different set fails on each full run. The pre-commit hook runs the full suite, so this blocks commits at random (it blocked a commit on #438 that did not touch Rust).

Observed on feat/invoice-redesign (Rust identical to main + api::invoice), 2026-09-12:

Run Result Failing tests
pre-commit hook, 1st commit of #438 509 passed —
pre-commit hook, review-round commit 506 passed, 3 failed api::disputes::tests::the_solver_pubkey_outlives_the_in_memory_record, api::orders::tests::replayed_cancel_over_terminal_trade_is_skipped, api::orders::tests::replayed_take_over_terminal_trade_has_no_side_effects
cargo test --lib, right after 507 passed, 2 failed api::disputes::tests::the_solver_pubkey_outlives_the_in_memory_record, api::nostr::relay_blacklist_restart_tests::a_removed_announced_relay_stays_out_across_a_restart_until_re_added
each test alone (--exact) all pass —
pre-commit hook, retry passed —

Where they panic

  • src/api/disputes.rs:1190 — after reopening the SQLite store, get_setting(&key) does not return the solver pubkey that was just written.
  • src/api/orders.rs:8133 and src/api/orders.rs:9698 — order_book().get_order(&order_id) after dispatching a replayed message: the cached order is missing or its status is not the expected terminal Success.

Likely cause (not verified)

All of them read or write process-global state — the order_book() cache, the app DB / settings store, the relay blacklist — that other tests running in parallel also mutate. That is the same shape as #309 (two locks, one global). The fix is probably either serialising these tests on the lock their globals already use, or giving each test its own isolated order id / DB path.

Repro

cd rust
for i in 1 2 3 4 5; do cargo test --lib 2>&1 | grep -E "^test result|FAILED"; done

🤖 Generated with Claude Code

https://claude.ai/code/session_01VDGyGeR7CkBALkZoRLFLnq

Dominant language
Dart
Stars
11
Forks
9
Avg merge
12h 41m
Merged PRs (30d)
265

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MostroP2P/app

All issues in MostroP2P/app

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.