fix(dash-spv): degrade gracefully when advisory file locking is unsupported (Android)#841
Conversation
…ported `LockFile::new()` treated any `TryLockError::Error` from `File::try_lock()` as fatal. On Android (`target_os = "android"`) the Rust standard library does not implement `flock`-based advisory locking and returns `ErrorKind::Unsupported` at compile time, so SPV storage init always failed with `Write failed: Failed to acquire lock: try_lock() not supported`, blocking the entire Core/SPV layer on Android. The lock file is only a best-effort guard against multiple processes sharing one data directory. On single-process platforms that lack advisory locking, proceeding without it is safe. Treat `ErrorKind::Unsupported` as non-fatal: skip the lock with a warning and continue. Genuine I/O errors and the already-locked (`WouldBlock`) case remain fatal, and the fast path on desktop/iOS is unchanged. Extract the classification into a `classify_lock_result` helper so the degradation path can be unit-tested with a synthesized `Unsupported` error (which never occurs naturally on Linux/macOS CI). Fixes #840 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## dev #841 +/- ##
==========================================
- Coverage 73.44% 73.38% -0.07%
==========================================
Files 324 324
Lines 72577 72616 +39
==========================================
- Hits 53306 53291 -15
- Misses 19271 19325 +54
|
Summary
Fixes #840.
On Android (
target_os = "android") the Rust standard library does not implementflock-based advisory file locking —File::try_lock()is a compile-time stub that unconditionally returnsErrorKind::Unsupported.LockFile::new()treated anyTryLockError::Erroras fatal, sodash-spvstorage init always failed with:This blocked the entire Core/SPV layer on Android — no header/filter sync, no balances, no L1 send. iOS, macOS, and Linux desktop were unaffected (their targets implement
flock).Fix
The lock file is only a best-effort guard against multiple processes sharing one data directory. On single-process platforms that lack advisory locking, proceeding without it is safe. This PR treats
ErrorKind::Unsupportedas non-fatal: skip the advisory lock with atracing::warn!and continue.WouldBlock(directory already in use) → still fatal (DirectoryLocked).WriteFailed).Unsupported→ warn and continue without the cross-process guard.Handling
ErrorKind::Unsupportedgenerically (rather than#[cfg(target_os = "android")]-gating) is more robust: it covers any non-flocktarget without special-casing.Testing
The classification logic is extracted into a small
classify_lock_resulthelper so the degradation path can be unit-tested with a synthesizedUnsupportederror — this never occurs naturally on Linux/macOS CI. Added tests cover all four outcomes:Ok(true)WouldBlock→DirectoryLockedUnsupported→Ok(false)(non-fatal, skip)WriteFailedAll existing lockfile tests continue to pass:
cargo fmt --checkandcargo clippy -p dash-spv --all-targets --all-featuresare clean.🤖 Generated with Claude Code