fix(dash-spv): handle buffered sync events during WaitingForConnections#768
fix(dash-spv): handle buffered sync events during WaitingForConnections#768xdustinface wants to merge 3 commits into
WaitingForConnections#768Conversation
…til after send
A `BlockHeaderSyncComplete` event delivered while `MasternodesManager` is in `WaitingForConnections` reaches `send_qrinfo_for_tip` with no peers connected. The previous order set state to `Syncing` before `requests.request_qr_info(...)?` propagated `Err("No connected peers")`, leaving the manager in `Syncing` with `qrinfo_in_flight = None`. `tick` only retries when `qrinfo_in_flight.is_some()` so the manager was stuck until the next external event.
Reorder so the state mutation only happens after the send and the in-flight bookkeeping have committed. On send failure the manager remains in `WaitingForConnections` and the next `start_sync` (or buffered `BlockHeaderSyncComplete` after reconnect) cleanly retries.
…connections `MasternodeStateUpdated` is a one-shot trigger that flips `masternode_ready` and forces `Synced`. A buffered event consumed while the manager is in `WaitingForConnections` (between `stop_sync` and the next `start_sync`) would force a peerless `Synced`, contradicting the network state. Gate `handle_sync_event` on `WaitingForConnections`. `on_disconnect` already resets `masternode_ready`, and `MasternodesManager` re-emits `MasternodeStateUpdated` from both `verify_and_complete` and `complete_incremental_pipeline` on the next sync cycle after reconnect, so dropping the buffered event loses nothing.
…r connections A buffered `MasternodeStateUpdated` consumed during `WaitingForConnections` would run `validate_pending` against state that `on_disconnect` already cleared. The existing `set_state(Synced)` was already gated on `Syncing | WaitForEvents` so state transitions were not affected, but the validation work itself is meaningless while peerless. Gate `handle_sync_event` on `WaitingForConnections`. `MasternodesManager` re-emits `MasternodeStateUpdated` on the next sync cycle after reconnect.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ 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✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## v0.42-dev #768 +/- ##
=============================================
+ Coverage 72.26% 72.65% +0.39%
=============================================
Files 320 320
Lines 70275 70292 +17
=============================================
+ Hits 50785 51072 +287
+ Misses 19490 19220 -270
|
1 participant
Three independent fixes for a class of races where sync events buffered in the broadcast channel get delivered to a manager while it sits in
SyncState::WaitingForConnections(betweenstop_syncand the nextstart_sync).MasternodesManager::send_qrinfo_for_tipno longer mutates state before the network send. OnErr("No connected peers")the manager stays inWaitingForConnectionsinstead of getting stranded inSyncingwithqrinfo_in_flight = None(whichtickcannot recover).ChainLockManager::handle_sync_eventdrops bufferedMasternodeStateUpdatedevents while inWaitingForConnections. Prevents a peerlessSyncedtransition. The event re-fires after reconnect viaverify_and_complete/complete_incremental_pipeline.InstantSendManager::handle_sync_eventdrops events the same way. Avoids runningvalidate_pendingagainst state thaton_disconnectalready cleared.