You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor initiate_async_payment to improve separation of concerns
1. Previously, `initiate_async_payment` handled both the outbound payment
state update (marking a static invoice as received) and the message
queuing for async payments. This tightly coupled two distinct
responsibilities within `ChannelManager`.
2. This refactor **separates concerns** by moving message queuing into
a separate function, allowing `initiate_async_payment` to focus solely
on updating `pending_outbound_payments`. This paves the way for moving
message queuing to `flow.rs` in upcoming commits, ensuring
`MessageRouter` logic remains independent of `ChannelManager`.
3. **This introduces a behavior change:** Since `pending_outbound_payments`
is now handled separately, we drop PersistenceNotifierGuard before queuing
messages. As a result, `NotifyOption` is no longer called for the message
queuing process.
4. **Why is this safe?** Because `pending_async_payments_messages` is
**not under `total_consistency_lock`**, meaning it does not require
persistence notifications. This aligns with the lock order tree and
maintains correct locking discipline.
By making this change, we improve modularity, enforce a cleaner separation
between `ChannelManager` and `MessageRouter`, and remove unnecessary
persistence dependencies.
0 commit comments