Summary
Follow-up to the lock-scope fix for the DPNS and DashPay profile passes. Two DashPay sync-manager paths still call the host persister while holding the wallet-manager write guard:
reconcile_incoming_payments → record_received_payment_totals(info, &self.persister, …) (wallet/identity/network/payments.rs ~37-72)reconcile_sent_payments_from_tx_history → managed.record_dashpay_payment(txid, entry, &self.persister) in a loop (~577-615), shared with the live record_incoming_dashpay_payments (~750-798)
record_dashpay_payment (state/managed_identity/identity_ops.rs ~145-188) rolls its in-memory insert back when the store fails, so the DPNS-style "collect and store after the guard" split needs a stage/unstage pair (stage under the guard, store outside, re-take the guard once to unstage on Err) rather than a buffering persister, which would silently break the retry guard.
Also in the same shape (one-off, lower cadence): sync_contact_requests_reporting ingest (contact_requests.rs ~1461/1510/1538) and discover_inner's add_identity / add_keys under the guard (discovery.rs ~450-490).
Why
The host store is synchronous and serialized behind FFIPersister::store's round_lock; while a slow commit runs (minutes on a 2000-tx wallet, see the persister issue) any store under the write guard holds the wallet-manager lock for that long and every reader — including the host UI — waits.
Related
Summary
Follow-up to the lock-scope fix for the DPNS and DashPay profile passes. Two DashPay sync-manager paths still call the host persister while holding the wallet-manager write guard:
reconcile_incoming_payments→record_received_payment_totals(info, &self.persister, …)(wallet/identity/network/payments.rs~37-72)reconcile_sent_payments_from_tx_history→managed.record_dashpay_payment(txid, entry, &self.persister)in a loop (~577-615), shared with the liverecord_incoming_dashpay_payments(~750-798)record_dashpay_payment(state/managed_identity/identity_ops.rs~145-188) rolls its in-memory insert back when the store fails, so the DPNS-style "collect and store after the guard" split needs a stage/unstage pair (stage under the guard, store outside, re-take the guard once to unstage onErr) rather than a buffering persister, which would silently break the retry guard.Also in the same shape (one-off, lower cadence):
sync_contact_requests_reportingingest (contact_requests.rs~1461/1510/1538) anddiscover_inner'sadd_identity/add_keysunder the guard (discovery.rs~450-490).Why
The host store is synchronous and serialized behind
FFIPersister::store'sround_lock; while a slow commit runs (minutes on a 2000-tx wallet, see the persister issue) anystoreunder the write guard holds the wallet-manager lock for that long and every reader — including the host UI — waits.Related