Replace maze of BOLT11 payment utilities with parameter generators by TheBlueMatt · Pull Request #2727 · lightningdevkit/rust-lightning

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt · 2023-11-10T19:35:19Z

lightning-invoice was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into ChannelManager. However, the old utilites remain.

Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed.

Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to ChannelManager. Those arguments can be further tweaked before passing them on, allowing more flexibility.

`lightning-invoice` was historically responsible for actually paying invoices, handling retries and everything. However, that turned out to be buggy and hard to maintain, so the payment logic was eventually moved into `ChannelManager`. However, the old utilites remain. Because our payment logic has a number of tunable parameters and there are different ways to pay a BOLT11 invoice, we ended up with six different methods to pay or probe a BOLT11 invoice, with more requested as various options still were not exposed. Instead, here, we replace all six methods with two simple ones which return the arguments which need to be passed to `ChannelManager`. Those arguments can be further tweaked before passing them on, allowing more flexibility.

codecov-commenter · 2023-11-10T19:46:45Z

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (6e40e5f) 88.80% compared to head (22305a9) 89.02%.
Report is 2 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@ Coverage Diff @@## main #2727 +/- ##
==========================================
+ Coverage 88.80% 89.02% +0.22% 
==========================================
Files 113 113 Lines 89170 89871 +701 Branches 89170 89871 +701 ==========================================
+ Hits 79188 80009 +821 + Misses 7729 7596 -133 - Partials 2253 2266 +13

Files	Coverage Δ
lightning-invoice/src/payment.rs	`96.45% <96.42%> (+19.38%)`	⬆️

... and 13 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

benthecarman · 2023-11-11T18:00:43Z

I think this closes #2390

TheBlueMatt · 2023-11-12T17:05:21Z

#2390 is about send_payment_with_path (and friends), not this. I actually thought about doing that in the same PR as well but its a bit more annoying since its used everywhere in tests.

Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

shaavan

ACK

The maze has been successfully navigated!

The latest sets of functions have been clarified, making optimal use of common functions wherever possible.
Additionally, the code is also well-documented.

I have also added a summary of my analysis of this PR, which can potentially help fellow contributors in their review process.

Summary:

Let's break it down function by function:

Simplifying Invoice Handling:
- pay_zero_value_invoice has been replaced with payment_parameters_from_zero_amount_invoice.
  - Removed retry strategy and ChannelManager from params.
  - Switched to using params_from_invoice instead of the convoluted pay_zero_value_invoice_with_id.
  - Added a check for a zero-amount invoice, eliminating the need for another function (pay_zero_value_invoice_with_id).
Cleaner Invoice Payment Process:
- pay_zero_value_invoice_with_id has been removed.
- pay_invoice_using_amount is now replaced with payment_parameters_from_invoice.
  - Instead of paying within this function, the process is sent to a common params_from_invoice function, reducing complexity.
  - The function now returns payment-related values upstream.
Streamlining Probing Functions:
- preflight_probe_invoice and preflight_probe_zero_value_invoice have been removed, as ChannelManager now handles the probing previously done here.
Enhancing Code Structure:
- Removed expiry_time_from_unix_epoch function, now using with_expiry_time defined within Payment Parameters.
Testing Improvements:
- Removed invoice and zero_value_invoice helper functions used in testing. Respective invoices are now created in their test functions.

valentinewallace

Good to wait on @G8XSU's ACK before landing.

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

TheBlueMatt mentioned this pull request Nov 10, 2023
Add max_total_routing_fee_msat for pay_invoice #2719
Closed

benthecarman reviewed Nov 11, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs Outdated

Drop old expiry_time_from_unix_epoch helper in expiry time lookup
22305a9
Since there's a much simpler way to go about it with `Bolt11Invoice::expires_at`.

TheBlueMatt force-pushed the 2023-11-better-bolt11-utils branch from cbf5fed to 22305a9Compare November 12, 2023 17:18

shaavan approved these changes Nov 13, 2023
View reviewed changes

G8XSU reviewed Nov 14, 2023
View reviewed changes

Comment threadlightning-invoice/src/payment.rs

valentinewallace approved these changes Nov 14, 2023
View reviewed changes

G8XSU approved these changes Nov 14, 2023
View reviewed changes

G8XSU merged commit 0456b0e into lightningdevkit:mainNov 14, 2023

Uh oh!

Conversation

TheBlueMatt commented Nov 10, 2023

Uh oh!

codecov-commenter commented Nov 10, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

benthecarman commented Nov 11, 2023

Uh oh!

TheBlueMatt commented Nov 12, 2023

Uh oh!

shaavan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

valentinewallace left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

TheBlueMatt commented Nov 10, 2023

Uh oh!

codecov-commenter commented Nov 10, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

benthecarman commented Nov 11, 2023

Uh oh!

TheBlueMatt commented Nov 12, 2023

Uh oh!

shaavan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

valentinewallace left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

TheBlueMatt commented Nov 10, 2023

Uh oh!

codecov-commenter commented Nov 10, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

benthecarman commented Nov 11, 2023

Uh oh!

TheBlueMatt commented Nov 12, 2023

Uh oh!

shaavan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

valentinewallace left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

codecov-commenter commented Nov 10, 2023•
edited
Loading

codecov-commenter commented Nov 10, 2023•
edited
Loading

codecov-commenter commented Nov 10, 2023•
edited
Loading

codecov-commenter commented Nov 10, 2023•
edited
Loading

codecov-commenter commented Nov 10, 2023•
edited
Loading