Skip to content

Backports for 0.1.3 #3757

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

Merged
merged 8 commits into from
Apr 30, 2025

Conversation

TheBlueMatt
Copy link
Collaborator

No description provided.

valentinewallace and others added 7 commits April 29, 2025 19:50
This bug was recently surfaced to us by a user who wrote a test where the
sender is attempting to route an MPP payment split across the two channels that
it has with its LSP, where the LSP has a single large channel to the recipient.

Previously this led to a pathfinding failure because our router was not sending
the maximum possible value over the first MPP path it found due to
overestimating the fees needed to cover the following hops. Because the path
that had just been found was not maxxed out, our router assumed that we had
already found enough paths to cover the full payment amount and that we were
finding additional paths for the purpose of redundant path selection. This
caused the router to mark the recipient's only channel as exhausted, with the
intention of choosing more unique paths in future iterations. In reality, this
ended up with the recipient's only channel being disabled and subsequently
failing to find a route entirely.

Update the router to fully utilize the capacity of any paths it finds in this
situation, preventing the "redundant path selection" behavior from kicking in.

Use and `rustfmt` conflicts resolved in:
 * lightning/src/blinded_path/payment.rs

The new test was also updated to avoid APIs not present on 0.1.
When calculating the maximum contribution of a path to a larger
route, we want to ensure we don't overshoot as that might cause us
to violate a maximum value limit.

In 209cb2a, we started by
calculating with `ceil`, which can trigger exactly that, so here we
drop the extra addition, switching us to `floor`.

Found both by the `router` fuzzer as well as the
`generate_large_mpp_routes` test.
`String::truncate` takes a byte index but panics if we split in the
middle of a UTF-8 codepoint. Sadly, in `InvoiceRequest::fields` we
want to tuncate the payer note to a maximum of 512 bytes, which may
be in the middle of a UTF-8 codepoint and can cause panic.

Here we iterate over the bytes in the string until we find one not
in the middle of a UTF-8 codepoint and then split the string there.

Trivial `rustfmt` conflicts resolved in:
 * lightning/src/offers/invoice_request.rs
In the next commit we attempt to verify `InvoiceRequest`s when
fuzzing so that we can test fetching the `InvoiceRequestFields`,
but its useful to allow the verification to succeed more often
first, which we do here.
This should allow us to reach the panic from two commits ago from
the fuzzer.
Ensures `InvoiceReceived` events are not generated multiple times
when `manually_handle_bolt12_invoice` is enabled.
Duplicate events for the same invoice could cause confusion—this
change introduces an idempotency check to prevent that.

Conflicts resolved in:
 * lightning/src/ln/outbound_payment.rs
due to the migration upstream from `max_total_routing_fee_msat` to
a more general config struct.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Apr 29, 2025

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-reviews-bot
Copy link

👋 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.

@wpaulino
Copy link
Contributor

Should we include b434ec8 to build with our MSRV?

@TheBlueMatt
Copy link
Collaborator Author

Mmm, yea, good point, done.

@ldk-reviews-bot ldk-reviews-bot requested a review from jkczyz April 30, 2025 00:10
@ldk-reviews-bot
Copy link

✅ Added second reviewer: @jkczyz

Copy link

codecov bot commented Apr 30, 2025

Codecov Report

Attention: Patch coverage is 97.10611% with 9 lines in your changes missing coverage. Please review.

Project coverage is 88.42%. Comparing base (9069cc3) to head (4deb527).
Report is 9 commits behind head on 0.1.

Files with missing lines Patch % Lines
lightning/src/blinded_path/payment.rs 81.48% 1 Missing and 4 partials ⚠️
lightning/src/offers/signer.rs 81.25% 2 Missing and 1 partial ⚠️
lightning/src/routing/router.rs 99.21% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##              0.1    #3757      +/-   ##
==========================================
+ Coverage   88.40%   88.42%   +0.01%     
==========================================
  Files         149      149              
  Lines      113859   114104     +245     
  Branches   113859   114104     +245     
==========================================
+ Hits       100659   100898     +239     
- Misses      10743    10749       +6     
  Partials     2457     2457              

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

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@jkczyz jkczyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM though CI is showing a couple packages needing a higher MSRV when running build-tx-sync.

@TheBlueMatt
Copy link
Collaborator Author

Yea, I think its fine to leave that at least for now.

@TheBlueMatt TheBlueMatt merged commit b8e48ac into lightningdevkit:0.1 Apr 30, 2025
21 of 27 checks passed
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.

9 participants