Uh oh!
There was an error while loading. Please reload this page.
Follow-up to #792 (multi-LSP support) - #956
Conversation
👋 Thanks for assigning @tnull as a reviewer! |
tnull
left a comment
There was a problem hiding this comment.
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.
| 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 { |
There was a problem hiding this comment.
That likely should be a cancellable task?
| /// 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> { |
There was a problem hiding this comment.
Not a fan of exposing this publicly. Retrying should not be the concern of a user?
There was a problem hiding this comment.
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
| .collect() | ||
| } | ||
| pub(crate) fn get_single_lsp_details( |
There was a problem hiding this comment.
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.
| loop { | ||
| let undiscovered_lsps = retry_ls.get_undiscovered_lsps(); | ||
| if undiscovered_lsps.is_empty() { | ||
| tokio::select! { |
There was a problem hiding this comment.
Hmm? If there's nothing to do, why do need this select?
There was a problem hiding this comment.
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.
| } | ||
| } | ||
| tokio::select! { |
There was a problem hiding this comment.
It seems an tokio::time::interval would be more suitable?
| for (node_id, address) in undiscovered_lsps { | ||
| if let Err(e) = | ||
| retry_cm.connect_peer_if_necessary(node_id, address.clone()).await |
There was a problem hiding this comment.
Hmm, this seems redundant to our general reconnection loop, or not?
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
da5bcdc to
b6da9a3Compareb6da9a3 to
27082aaCompare| connect_and_discover_lsp(&cm, &ls, &logger, node_id, address).await; | ||
| }); | ||
| } | ||
| discovery_set.join_all().await; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| backoff *= 2; | ||
| } | ||
| // periodically re-discover all configured LSPs to pick up newly |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
27082aa to
78c313fCompare| _ = tokio::time::sleep(backoff) => {}, | ||
| } | ||
| let undiscovered_lsps = rediscovery_ls.get_undiscovered_lsps(); |
There was a problem hiding this comment.
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.
| node_id: PublicKey, | ||
| } | ||
| impl Drop for PendingDiscoveryGuard<'_> { |
There was a problem hiding this comment.
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.
| backoff *= 2; | ||
| } | ||
| // periodically re-discover all configured LSPs to pick up newly |
There was a problem hiding this comment.
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
78c313f to
48104f7CompareCamillarhi
commented
Jul 21, 2026
Uh oh!
There was an error while loading. Please reload this page.
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_0confindependent 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