Skip to content
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

pay: Track payment completion time for successful payments #5398

Merged
merged 5 commits into from
Sep 14, 2022

Conversation

cdecker
Copy link
Member

@cdecker cdecker commented Jul 10, 2022

Track completion time for succesful payments

BY adding the completed_at field to the payments table, and the
sendpay, listsendpays and waitsendpay output we can derive the
completion time for a payment by taking the lowest completed_at
among all parts that were sent. By definition the earliest successful
part guarantees that the payment as a whole will complete, even if
some parts are delayed or stuck. This is because any successful part
communicates the payment_preimage which is the same across all
parts.

For unsuccessful payments we might want to use the first
completed_at after the last created_at time, i.e., the first part
that did not cause a new part to be sent. This usually means we ran
out of routes or time, and pay didn't start any new attempts. Is
that a good interpretation of the completion time for unsuccessful
payments?

@niftynei
Copy link
Collaborator

postgres is unhappy


lightningd-1 2022-07-10T14:09:52.886Z **BROKEN** lightningd: s32 field doesn't match size: expected 1, actual 1?
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: FATAL SIGNAL 6 (version 64534d8-modded)
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x55f9f5c76f70
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: common/daemon.c:46 (crashdump) 0x55f9f5c76fc4
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 ((null)) 0x7f727f63008f
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: ../sysdeps/unix/sysv/linux/raise.c:51 (__GI_raise) 0x7f727f63000b
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79 (__GI_abort) 0x7f727f60f858
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: lightningd/log.c:851 (fatal_vfmt) 0x55f9f5c19c69
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: wallet/wallet.c:61 (db_fatal) 0x55f9f5c55930
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: db/db_postgres.c:190 (db_postgres_column_int) 0x55f9f5cdc08d
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: db/bindings.c:54 (db_col_int) 0x55f9f5c963c7
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: wallet/wallet.c:3247 (wallet_stmt2payment) 0x55f9f5c5e7a5
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: wallet/wallet.c:3299 (wallet_payment_by_hash) 0x55f9f5c5e8c0
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: lightningd/pay.c:341 (payment_succeeded) 

@niftynei niftynei added this to the v22.10 milestone Jul 11, 2022
@cdecker
Copy link
Member Author

cdecker commented Jul 11, 2022

Got it, the column was wrongly set to be BIGINT whereas it should be INTEGER, that explains the mistmatch.

We'll want to use these to track durations for `sendpays` and `pays`.
The completion of a successful payment is defined as the first
completion of a successful part, hence we just collect the minimum
completion time of successes.

Changelog-Added: JSON-RPC: `pay` and `listpays` now lists the completion time.
@cdecker
Copy link
Member Author

cdecker commented Sep 14, 2022

ACK e7511a4

@cdecker cdecker merged commit f64d755 into ElementsProject:master Sep 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants