Fix StaticInvoice::is_offer_expired to check the offer's expiry#4594
Conversation
The std-only `StaticInvoice::is_offer_expired` accessor delegated to `InvoiceContents::is_expired`, which compares `created_at + relative_expiry` against the current time — that is the *invoice*'s expiry, not the offer's. The `_no_std` sibling and `flow.rs:: enqueue_static_invoice` already treat the two as distinct checks. A payer or forwarder using the std API to decide whether to honor a static invoice would therefore get the wrong answer in either direction: forwarding offers the issuer has already retired (when the invoice is still fresh), or refusing offers that are still valid (when the invoice has aged past its `relative_expiry` but the offer itself has no `absolute_expiry`). Route the std accessor through `InvoiceContents::is_offer_expired` so both the std and no-std paths consult the offer's expiry. Co-Authored-By: HAL 9000
|
👋 Thanks for assigning @valentinewallace as a reviewer! |
|
No remaining misuse of No issues found. |
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4594 +/- ##
==========================================
- Coverage 86.84% 86.24% -0.60%
==========================================
Files 161 159 -2
Lines 109260 109196 -64
Branches 109260 109196 -64
==========================================
- Hits 94882 94177 -705
- Misses 11797 12408 +611
- Partials 2581 2611 +30
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Going ahead landing this. |
|
This method was added in 0.2 so no need to backport to 0.1. |
|
Backported to 0.2 in #4683. |
5 participants
The std-only
StaticInvoice::is_offer_expiredaccessor delegated toInvoiceContents::is_expired, which comparescreated_at + relative_expiryagainst the current time — that is the invoice's expiry, not the offer's. The_no_stdsibling andflow.rs:: enqueue_static_invoicealready treat the two as distinct checks.A payer or forwarder using the std API to decide whether to honor a static invoice would therefore get the wrong answer in either direction: forwarding offers the issuer has already retired (when the invoice is still fresh), or refusing offers that are still valid (when the invoice has aged past its
relative_expirybut the offer itself has noabsolute_expiry).Route the std accessor through
InvoiceContents::is_offer_expiredso both the std and no-std paths consult the offer's expiry.Co-Authored-By: HAL 9000