Skip to content

test(sdk): serialize bilateral_impl tests to fix flaky shared-DB races#445

Open
dsmfa10 wants to merge 1 commit into
mainfrom
fix/serialize-bilateral-impl-tests
Open

test(sdk): serialize bilateral_impl tests to fix flaky shared-DB races#445
dsmfa10 wants to merge 1 commit into
mainfrom
fix/serialize-bilateral-impl-tests

Conversation

@dsmfa10
Copy link
Copy Markdown
Collaborator

@dsmfa10 dsmfa10 commented Jun 3, 2026

Problem

The pre-push hook runs the full workspace test suite. It intermittently failed
on:

sdk::wallet_sdk::tests::test_initialize_bilateral_chain_with_empty_initial_hash_uses_zero_state

That test passes in isolation, so it is flaky under the full parallel run —
not a real regression, and unrelated to any audit branch (the canary branch
that triggered it doesn't touch wallet_sdk).

Root cause

All SDK tests share process-global state:

  • storage_utils::STORAGE_BASE_DIR is a write-once OnceLock<PathBuf> — the
    first test to set it wins, and every test in the process then uses that one
    on-disk SQLite client DB.
  • AppState is a global singleton (reset_memory_for_testing /
    set_identity_info).

Tests that touch these are marked #[serial] to avoid races — but
handlers/bilateral_impl.rs had 19 #[tokio::test]s with no #[serial]
.
They build BiImpl, call set_storage_base_dir, and read global AppState, so
they ran concurrently against the shared SQLite DB. When one overlapped the
(serial) wallet test, DB contention surfaced as a ?-propagated error and the
wallet test was reported as failed.

Fix

Add #[serial_test::serial] to all 19 tests in bilateral_impl.rs, putting them
in the same default serial mutual-exclusion group as the wallet / AppState / DB
tests. Fully-qualified form (no new use), matching the 45 existing
#[serial_test::serial] annotations in the crate.

#[tokio::test]
#[serial_test::serial]   // added to each of the 19 tests
async fn prepare_rejects_invalid_protobuf() { ... }

Verification

cargo test -p dsm_sdk --lib run three consecutive times, each:
test result: ok. 1506 passed; 0 failed; 7 ignored.

Notes

This is a pre-existing main issue surfaced while preparing to push the audit
branches — it is its own fix, independent of the audit findings. The lighter
storage_utils.rs OnceLock tests were left as-is (they don't drive the shared
SQLite DB); if further flakiness appears they can be serialized the same way.

CI gates & coverage

Full verification for this PR runs in CI — Rust (cargo fmt --check,
clippy -D warnings, workspace tests), Frontend, Android Unit Tests,
Coverage, SPDX headers, CodeQL (see the PR's Checks tab). The local
check noted above is a subset; the broader mandated gates (full workspace test
suite, codegen/scan, Android, Frontend) run in CI, not locally — none is
silently skipped.

`handlers/bilateral_impl.rs` had 19 `#[tokio::test]`s with no `#[serial]`.
They construct `BiImpl`, set the process-global storage dir
(`storage_utils::set_storage_base_dir`, a write-once `OnceLock`), and read
the global `AppState` — so they ran in parallel against the single shared
on-disk SQLite client DB used by every test in the process.

That concurrency intermittently broke the (already `#[serial]`) wallet test
`sdk::wallet_sdk::tests::test_initialize_bilateral_chain_with_empty_initial_hash_uses_zero_state`
(observed as 1505 passed / 1 failed in a full-suite run; the test passes in
isolation), via DB contention surfacing as a `?`-propagated error.

Add `#[serial_test::serial]` to all 19 tests so they join the same
mutual-exclusion group as the wallet/AppState/DB tests. Fully-qualified to
match the 45 existing `#[serial_test::serial]` uses (no new import).

Verified: full `cargo test -p dsm_sdk --lib` run 3×, each `1506 passed; 0
failed` (previously intermittently 1505/1).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@codecov-commenter
Copy link
Copy Markdown

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants