-
Notifications
You must be signed in to change notification settings - Fork 97
Update sample for 0.0.103 #40
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
Conversation
956a237
to
16779b1
Compare
16779b1
to
e31773b
Compare
println!("ERROR: failed to send payment: {:?}", e); | ||
print!("> "); | ||
HTLCStatus::Failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we treat no-route differently from all-routes-failed-immediately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure... was just trying to maintain the same behavior. ChannelManager
never gets called in this case, so maybe there's no need to update the payment storage? (cc: @valentinewallace)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm yeah I don’t think either would make sense to put in PaymentStorage. Don’t recall my exact reasoning tho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, I think don't bother to store them? I'm not even sure if we need to store outbound payments anyway at this point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not even sure if we need to store outbound payments anyway at this point?
list_payments
currently allows you to see whether an outbound payment is pending vs completed/failed, due to storing them here. Could be exposed from ChannelManager
instead tho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yeah and right now neither inbound nor outbound payments are persisted in the sample. They're just used in list_payments
. I can drop them entirely. Just want to note that it seems independent of the PR. Happy to do it here in a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, lets do it in a followup and land this for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... so won't ChannelManager
eventually remove the payments after they've been fulfilled? The sample would still needs to keep track of these, right? The idea of list_payments
is basically a transaction log, IIUC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... so won't
ChannelManager
eventually remove the payments after they've been fulfilled? The sample would still needs to keep track of these, right? The idea oflist_payments
is basically a transaction log, IIUC.
I second this, though payments are currently not persisted to disk in the sample. So IMO inbound/outbound tracking shouldn’t be removed
let payee = Payee::for_keysend(payee_pubkey); | ||
let params = RouteParameters { payee, final_value_msat: amt_msat, final_cltv_expiry_delta: 40 }; | ||
|
||
let route = match router::find_route( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmmmm, we really need to get InvoicePayer
to support spontaneous payments eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, just opened issue lightningdevkit/rust-lightning#1156. Happy to take it on.
Update the sample node to use APIs from the 0.0.103 release.
InvoicePayer
for routing and sending paymentsfind_route
for keysend paymentsScorer
instance and persist it periodically