Log which hop in a path was the most limiting in capacity #3729
Conversation
This file contains 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
This bug was recently surfaced to us by a user who wrote a test where the sender is attempting to route an MPP payment split across the two channels that it has with its LSP, where the LSP has a single large channel to the recipient. Previously this led to a pathfinding failure because our router was not sending the maximum possible value over the first MPP path it found due to overestimating the fees needed to cover the following hops. Because the path that had just been found was not maxxed out, our router assumed that we had already found enough paths to cover the full payment amount and that we were finding additional paths for the purpose of redundant path selection. This caused the router to mark the recipient's only channel as exhausted, with the intention of choosing more unique paths in future iterations. In reality, this ended up with the recipient's only channel being disabled and subsequently failing to find a route entirely. Update the router to fully utilize the capacity of any paths it finds in this situation, preventing the "redundant path selection" behavior from kicking in.
|
I've assigned @valentinewallace as a reviewer! |
TheBlueMatt
force-pushed
the
2025-04-log-limited-hop
branch
from
1ff1208 to
2d41456
Compare
tnull
reviewed
Apr 11, 2025
|
🔔 1st Reminder Hey @valentinewallace! This PR has been waiting for your review. |
Its generally rather difficult to debug the pathfinding logic from a log, and sadly because we cannot feasibly log each step in a pathfinding search there's relatively few options we have for improving this. However, one specific question we occasionally get is "why did the pathfinder decide to use MPP"? While we similarly cannot practically log every possible path the pathfinder could have taken to explain why a specific path which required MPP was taken, we can at least explain which hop in the path was the most limited, which we do here.
TheBlueMatt
force-pushed
the
2025-04-log-limited-hop
branch
from
2d41456 to
056d5da
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Its generally rather difficult to debug the pathfinding logic from
a log, and sadly because we cannot feasibly log each step in a
pathfinding search there's relatively few options we have for
improving this.
However, one specific question we occasionally get is "why did the
pathfinder decide to use MPP"? While we similarly cannot
practically log every possible path the pathfinder could have taken
to explain why a specific path which required MPP was taken, we can
at least explain which hop in the path was the most limited, which
we do here.
Based on #3707