-
Notifications
You must be signed in to change notification settings - Fork 403
Improve logging of pathfinding behavior #1646
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
Comments
Hey i,d like to try this issue. |
And i am new to opensource, so i may need guidance. |
Welcome! The relevant parts of the code can be found in the Then you'll have to figure out for which cases it makes sense to add logging lines (probably in |
Thanks |
Hey @tnull, thanks for the explanation, but I still find it hard to understand this issue. Please provide some material to understand the code. |
Mh, could you be a bit more specific on what you're having trouble understanding? Also, feel free to find me on LDK Discord and we can discuss this a bit more interactively. |
Yeah, I am finding it hard to understand code in |
Yep, feel free to reach out. |
Ok |
Hello @tnull, I have spent some time in understanding LDK and I would like to work on this issue can you pls assign this to me ? |
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
Previously, we barely gave any hints why we excluded certain hops during pathfinding. Here, we introduce more verbose logging by a) accounting how much candidates we ignored for which reasons and b) logging any first/last/blinded hops we end up ignoring. Fixes lightningdevkit#1646.
The behavior of sending a payment can be quite confusing to users, in particular if an otherwise obvious channel choice is avoided without giving any feedback as to why.
We therefore should try to improve the logging in
get_route
without getting too spammy. In particular, we should find a way to give users feedback when for example a direct channel is avoided due to lacking channel reserves, its value contribution, or similar.The text was updated successfully, but these errors were encountered: