Skip to content

Fix: Remove Unnecessary &mut self Requirements from LightningNode Trait #284

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

mubarak23
Copy link

This PR refactors the LightningNode trait and its implementations to remove unnecessary &mut self references for methods that do not mutate internal state.

Motivation

Previously, several trait methods like get_network and list_channels required &mut self, even though they only retrieved information. This requirement leaked internal implementation details—specifically, that the underlying client field required a mutable reference to make gRPC or HTTP calls.

This design was misleading and unnecessarily restricted usage of the trait, e.g. preventing multiple read-only operations from being performed concurrently on the same node.

Changes

Wrapped client fields (e.g. NodeClient, EclairClient, etc.) inside tokio::sync::Mutex.

Updated all client usages to acquire a mutable lock via let mut client = self.client.lock().await;.

Updated trait method signatures to require &self instead of &mut self where applicable.

Ensured thread-safe, concurrent-friendly behavior without sacrificing correctness or clarity.

@mubarak23 mubarak23 marked this pull request as draft June 13, 2025 15:11
Copy link
Contributor

@carlaKC carlaKC left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cACK, heading in the right direction 👍

@@ -495,7 +495,7 @@ pub struct SimNode<'a, T: SimNetwork> {
/// The underlying execution network that will be responsible for dispatching payments.
network: Arc<Mutex<T>>,
/// Tracks the channel that will provide updates for payments by hash.
in_flight: HashMap<PaymentHash, Receiver<Result<PaymentResult, LightningError>>>,
in_flight: Mutex<HashMap<PaymentHash, Receiver<Result<PaymentResult, LightningError>>>>, // HashMap<PaymentHash, Receiver<Result<PaymentResult, LightningError>>>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: unnecessary comment at the end?

@@ -523,7 +523,7 @@ impl<'a, T: SimNetwork> SimNode<'a, T> {
SimNode {
info,
network: payment_network,
in_flight: HashMap::new(),
in_flight: HashMap::new().into(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitnit: this reads a bit odd in my very subjective opinion, just use Mutex::new

Comment on lines 633 to 634
let mut in_flight = self.in_flight.lock().await;
match in_flight.entry(payment_hash) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO can inline things like this without losing much readability

@mubarak23 mubarak23 marked this pull request as ready for review June 16, 2025 09:49
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