CI: Windows dashd_sync tests intermittently fail during node startup

[thepastaclaw]

Summary

The Windows dash-spv dashd_sync integration suite intermittently fails while starting its per-test Dash Core nodes. The failing test names vary, but the failure signature is consistent:

• dashd failed to start within timeout at dash-spv/src/test_utils/node.rs:188
• failed to create wallet 'default' ... Database already exists at dash-spv/src/test_utils/node.rs:265

Evidence

• PR fix(key-wallet): discover Coinbase/AssetUnlock outputs for all fund-bearing accounts #901, Windows / spv: https://github.com/dashpay/rust-dashcore/actions/runs/29502822011/job/87635842091
  • Failed test_mempool_to_confirmed_lifecycle, test_runtime_add_during_initial_sync, and test_runtime_add_shared_block_two_wallets.
  • The PR changes only four key-wallet transaction-routing/test files; it does not change dash-spv or the integration-test harness.
• PR feat(key-wallet): stamp retained transaction records with their in-block position #891, Windows / spv: https://github.com/dashpay/rust-dashcore/actions/runs/29331523490/job/87080357867
  • Failed test_runtime_add_with_tip_advance_during_rescan, test_sync_restart_consistency, and test_sync_restart_with_fresh_wallet with the same two failure modes.
  • That PR also changed only key-wallet/key-wallet-manager files and was merged without an SPV change.

All corresponding Ubuntu, Ubuntu ARM, and macOS SPV jobs passed in both runs. The varying test names and repeated Windows-only startup/wallet failures indicate shared integration-test infrastructure flakiness rather than test assertions tied to either PR.

Reproduction

On a Windows runner, provision Dash Core and the regtest fixture with contrib/setup-dashd.py, then repeatedly run the suite with its default test concurrency:

cargo test -p dash-spv --test dashd_sync

The suite launches many independent Dash Core processes in parallel. Under the failing runs, some processes do not become ready within the fixed 30-second window, and one process reaches the load_wallet/create_wallet fallback after the default database path already exists.

Investigation notes

• Capture/retain the failing node's dashd log on Windows; both referenced jobs reported no retained artifacts.
• Check whether Windows runner resource pressure requires bounded integration-test concurrency or a longer readiness deadline.
• Make ensure_wallet distinguish a missing wallet from transient load errors and an already-created database instead of treating every load_wallet error as permission to call create_wallet.