Conversation
A failed payment was only reported as the index of the last hop that its htlc was added on, which does not identify the channel that rejected it. Report that channel so that the sending node can act on it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The scorer call in `track_payment` passed the index of the hop that a htlc failed on where LDK expects the failed channel's short channel id. It never matched a channel on the path, so LDK scored every hop of a failed path as having sufficient liquidity. Give the scorer the channel that the network blamed for the failure instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A payment whose htlc was rejected while being added along its route reported a `htlc_count` of zero, even though a htlc had been dispatched for it. Count it, as lnd does, so that the column reports what the payment attempted rather than only what succeeded. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`track_payment` both waited on the shutdown listener and resolved the payment's outcome in one `select!` arm. Resolving a payment is about to become a loop, so give it its own function and leave `track_payment` to race it against shutdown. No behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A simulated node reported a payment as failed as soon as its htlc was rejected, where real nodes re-route it and try again. Resolving a payment is now a loop. When the network blames a channel for rejecting the htlc, that channel is added to `previously_failed_channels` and the payment is re-routed and dispatched again under the same hash, up to `MAX_RETRIES` (5). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
needed a rebase after #319 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds a payment retries when running in a simulated network. It just sets it to at max try 5.
Note that there was a bug in the reporting to the scorer. While re-working the outcomes to also report the channels where a route failed, (claude) noticed that this was reporting the failure to the scorer with just an index casted as a u64 where LDK is expecting a
scid. This is fixed in 85b213dThe retries approach just takes the channel at which the payment failed and passes it to LDK to ignore when calculating the route for the next retry