Follow-up to #792 (multi-LSP support) by Camillarhi · Pull Request #956 · lightningdevkit/ldk-node

Camillarhi · 2026-07-01T11:18:33Z

Some minor follow-ups after #792 landed.

Retry LSP protocol discovery when it fails at startup, so a transient connection failure doesn't leave a configured LSP permanently unusable. Adds a background retry with backoff and a Liquidity::retry_discovery(node_id) method for on-demand re-discovery (also useful when an LSP rolls out a new protocol).
Honor trust_peer_0conf independent of the LSP's supported protocols, It was previously only applied to LSPS2 peers, so LSPS1-only or undiscovered LSPs silently lost their configured 0-conf trust.

Leaving the LSP feature-gating for #900

Fixes - #936

ldk-reviews-bot · 2026-07-02T01:24:00Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tnull

Excuse the delay here. Second commit seems broken, please avoid the unrelated changes as otherwise it's not really reviewable. Also needs a minor rebase by now.

tnull · 2026-07-09T08:49:25Z

+		let retry_ls = Arc::clone(&self.liquidity_source);
+		let retry_logger = Arc::clone(&self.logger);
+		let retry_cm = Arc::clone(&self.connection_manager);
+		self.runtime.spawn_background_task(async move {


That likely should be a cancellable task?

tnull · 2026-07-09T08:50:12Z

+	/// The `node_id` must belong to an LSP configured at build time or added via
+	/// [`Liquidity::add_liquidity_source`]; otherwise [`Error::LiquiditySourceUnavailable`]
+	/// is returned.
+	pub fn retry_discovery(&self, node_id: PublicKey) -> Result<(), Error> {


Not a fan of exposing this publicly. Retrying should not be the concern of a user?

It was meant to let a user trigger re-discovery for an LSP they know has rolled out a new protocol, the background retry only covers LSPs that never completed discovery in the first place, so an already-discovered LSP adding a protocol wouldn't get picked up.
But thinking about it more, the user usually won't know when an LSP adds a protocol, so leaning on them to call this isn't great. Probably makes more sense to have the background task periodically re-run discovery for already-discovered LSPs too, so new protocols get picked up automatically and there's nothing to expose. I will extend the background check

tnull · 2026-07-09T08:52:40Z

 			.collect()
 	}

+	pub(crate) fn get_single_lsp_details(


Please avoid such ~single-call helpers (especially if they are only used in one place). Please rather inline them so they don't clutter up the file as much.

tnull · 2026-07-09T08:53:52Z

+			loop {
+				let undiscovered_lsps = retry_ls.get_undiscovered_lsps();
+				if undiscovered_lsps.is_empty() {
+					tokio::select! {


Hmm? If there's nothing to do, why do need this select?

It is there to stop the loop from busy-spinning when there's nothing to discover. The idea was to keep the task alive in case an LSP became undiscovered later, but a runtime add_liquidity_source cleans up the node if its discovery fails, so nothing new ever lands in the undiscovered set after startup. So once it's empty, there's nothing to wait for, and it should just return. I'll clean it up as part of the re-discovery rework, for re-discovering already-discovered LSPs.

tnull · 2026-07-09T08:55:06Z

+					}
+				}
+
+				tokio::select! {


It seems an tokio::time::interval would be more suitable?

tnull · 2026-07-09T08:56:04Z

+
+				for (node_id, address) in undiscovered_lsps {
+					if let Err(e) =
+						retry_cm.connect_peer_if_necessary(node_id, address.clone()).await


Hmm, this seems redundant to our general reconnection loop, or not?

Configured LSPs aren't added to the peer store at startup, so the reconnection loop doesn't keep them connected. This is what connects us to run discovery.

tnull

Two minor comments.

tnull · 2026-07-14T12:07:23Z

+						connect_and_discover_lsp(&cm, &ls, &logger, node_id, address).await;
+					});
+				}
+				discovery_set.join_all().await;


Codex:

[P2] Make rediscovery cancellation-safe — /home/tnull/worktrees/ldk-node/pr-956/src/lib.rs:798

Node::stop() aborts this task while join_all() may be awaiting an LSPS0 request. Dropping discover_lsp_protocols bypasses its timeout cleanup, leaving the node ID permanently present in pending_lsps0_discovery. After restarting the same Node, every discovery attempt reports “already in
flight,” preventing protocol refresh unless the old response eventually arrives. Use drop-based cleanup for pending requests or allow in-flight discovery tasks to finish during shutdown.

Fixed with drop-based cleanup, a guard now removes the pending entry when the discovery future is dropped, so an aborted task can't leave a stale "in flight" entry behind.

tnull · 2026-07-14T12:11:29Z

+				backoff *= 2;
+			}
+
+			// periodically re-discover all configured LSPs to pick up newly


Are we positive we need this? I think when an LSP updates it's fine to only discover that on next reconnection. And wouldn't peers that never finish discovery also be retried above?

Are we positive we need this? I think when an LSP updates it's fine to only discover that on next reconnection.

Unused LSPs aren't persisted to the peer store, so the reconnection loop won't cover them, and discovery doesn't currently run on reconnection, but I could watch for when an LSP disconnects and re-run discovery once it reconnects.

And wouldn't peers that never finish discovery also be retried above?

The retry loop above this only covers never-discovered peers until the backoff caps out, after that the sweep is what keeps retrying them. If I swap the sweep for the rediscover-on-reconnect approach, I'd let the retry loop keep going at the cap instead, so those stay covered.

I'm confused: we now have two APIs, right? Users can either add LSPs at build time, or at runtime. Both are not persisted, but the build-time one is likely 'persisted' in the user code. Why do we need to 'rediscover' these configured LSPs during the runtime - do we really expect our nodes to never restart and we hence require live protocol upgrades? I'm not sure we need to / should.

This is correct, a restart will cover this. I'll drop the rediscovery for already-discovered LSPs and keep only the retry for the ones where the initial discovery failed, running at the capped backoff until they come up, and stopping once there's nothing left undiscovered

tnull

Some comments that Codex had, mostly.

The cancellation safety part is now also addressed in #997.

tnull · 2026-07-20T11:07:20Z

+						_ = tokio::time::sleep(backoff) => {},
+				}
+
+				let undiscovered_lsps = rediscovery_ls.get_undiscovered_lsps();


Codex:

[P2] Background discovery can make add_liquidity_source fail spuriously. The /home/tnull/worktrees/ldk-node/pr-956-latest/src/lib.rs:760 can select a runtime-added LSP after it is inserted with supported_protocols: None but before /home/tnull/worktrees/ldk-node/pr-956-latest/src/liquidity/
mod.rs:156. If the background task claims the pending-discovery slot first, the public call receives LiquidityRequestFailed and removes the otherwise valid LSP. Same-node discovery should be coalesced or initializing entries excluded from background sweeps.

tnull · 2026-07-20T11:07:48Z

+	node_id: PublicKey,
+}
+
+impl Drop for PendingDiscoveryGuard<'_> {


Codex

[P2] An old discovery guard can delete a newer request. The response handler removes the pending sender before waking its receiver, while /home/tnull/worktrees/ldk-node/pr-956-latest/src/liquidity/mod.rs:364 later removes whichever entry currently exists for that node. A second discovery
can insert during that gap, only to have the first guard delete its sender. The guard should be disarmed after receiving its response or verify request identity before removal.

tnull · 2026-07-20T11:18:13Z

+				backoff *= 2;
+			}
+
+			// periodically re-discover all configured LSPs to pick up newly


I'm confused: we now have two APIs, right? Users can either add LSPs at build time, or at runtime. Both are not persisted, but the build-time one is likely 'persisted' in the user code. Why do we need to 'rediscover' these configured LSPs during the runtime - do we really expect our nodes to never restart and we hence require live protocol upgrades? I'm not sure we need to / should.

Add a background task that retries discovery for LSPs still undiscovered after the startup batch, with exponential backoff (5s up to a 1h cap), until every configured LSP is discovered. This recovers LSPs that were unreachable at startup instead of leaving them permanently unusable. Also coalesce concurrent discovery for the same LSP, so the retry task and a runtime add_liquidity_source don't race and needlessly fail.

Look up trust_peer_0conf by node id via a protocol-independent helper that does not depend on discovery

Camillarhi · 2026-07-21T01:14:10Z

Some comments that Codex had, mostly.

The cancellation safety part is now also addressed in #997.

Thanks, I reverted the cancellation-safety guard since #997 covers it. If #997 lands first, I'll rebase on top of it.

ldk-reviews-bot requested a review from tnull July 2, 2026 01:34

tnull reviewed Jul 9, 2026

View reviewed changes

Camillarhi force-pushed the multi-lsp-support-follow-up branch from da5bcdc to b6da9a3 Compare July 9, 2026 20:38

Camillarhi requested a review from tnull July 9, 2026 20:42

Camillarhi force-pushed the multi-lsp-support-follow-up branch from b6da9a3 to 27082aa Compare July 10, 2026 12:01

tnull reviewed Jul 14, 2026

View reviewed changes

Camillarhi force-pushed the multi-lsp-support-follow-up branch from 27082aa to 78c313f Compare July 15, 2026 13:59

Camillarhi requested a review from tnull July 15, 2026 14:01

tnull reviewed Jul 20, 2026

View reviewed changes

Camillarhi added 2 commits July 21, 2026 02:02

Honor LSP trust_peer_0conf independent of supported protocols

48104f7

Look up trust_peer_0conf by node id via a protocol-independent helper that does not depend on discovery

Camillarhi force-pushed the multi-lsp-support-follow-up branch from 78c313f to 48104f7 Compare July 21, 2026 01:06

Camillarhi requested a review from tnull July 21, 2026 01:14

tnull approved these changes Jul 21, 2026

View reviewed changes

tnull merged commit 08efb3a into lightningdevkit:main Jul 21, 2026
24 of 36 checks passed

tnull mentioned this pull request Jul 21, 2026

Release completed cancellable tasks #997

Open

Uh oh!

Conversation

Camillarhi commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Camillarhi commented Jul 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Camillarhi commented Jul 1, 2026 •

edited

Loading

ldk-reviews-bot commented Jul 2, 2026 •

edited

Loading