Skip to content

Scope payment preimage in do_test_keysend_payments #2481

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

Conversation

TheBlueMatt
Copy link
Collaborator

b0d4ab8 fixed a nasty bug where
we'd failed to include the payment preimage in keysend onions at
all. Ultimately, this was a test failure - the existing test suite
should which did keysend payments were not structured in a way that
would fail in this case, instead using the same preimage variable
both for sending and receiving.

Here we improve the main keysend test tweaked by b0d4ab8
to make absolutely sure it cannot work if the preimage doesn't come
from the onion. We make the payment preimage on the sending side a
variable inside a scope which only exists for the send call. Once
that scope completes the payment preimage only exists in the
sending ChannelManager, which must have put it in the onion in
order for the receiving node to have it.

b0d4ab8 fixed a nasty bug where
we'd failed to include the payment preimage in keysend onions at
all. Ultimately, this was a test failure - the existing test suite
should which did keysend payments were not structured in a way that
would fail in this case, instead using the same preimage variable
both for sending and receiving.

Here we improve the main keysend test tweaked by b0d4ab8
to make absolutely sure it cannot work if the preimage doesn't come
from the onion. We make the payment preimage on the sending side a
variable inside a scope which only exists for the send call. Once
that scope completes the payment preimage only exists in the
sending `ChannelManager`, which must have put it in the onion in
order for the receiving node to have it.
Doing `cargo test` causes us to build both the crate(s) themselves
and the test binaries, which depend on the main builds. However, it
can start building the test code while the actual program code for
the main crate(s) themselves are being built, making a
build -> test flow slightly slower than test -> build.

Its not really a huge deal, but I'm using `ci/ci-tests.sh` more
locally and it meaningfully changes the time-to-test-run.
@codecov-commenter
Copy link

codecov-commenter commented Aug 8, 2023

Codecov Report

Patch coverage: 93.33% and project coverage change: -0.01% ⚠️

Comparison is base (100fdbb) 90.33% compared to head (67e5399) 90.33%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2481      +/-   ##
==========================================
- Coverage   90.33%   90.33%   -0.01%     
==========================================
  Files         106      106              
  Lines       55771    55775       +4     
  Branches    55771    55775       +4     
==========================================
+ Hits        50382    50384       +2     
- Misses       5389     5391       +2     
Files Changed Coverage Δ
lightning/src/ln/payment_tests.rs 97.66% <93.33%> (-0.05%) ⬇️

... and 2 files with indirect coverage changes

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

@tnull
Copy link
Contributor

tnull commented Aug 8, 2023

FWIW, now also introduced test coverage for spontaneous payments in LDK Node (lightningdevkit/ldk-node#151).

@TheBlueMatt
Copy link
Collaborator Author

Will let @alecchendev take a look here, I don't really care much about this, just wanted to demonstrate what I think makes a good test for this kinda thing and will let him comment.

@alecchendev
Copy link
Contributor

alecchendev commented Aug 8, 2023

This makes sense to me. I was thinking we should technically hit the "We require payment secrets" onion error in this single-path keysend test (which is how I ended up finding the bug), but now that we accept payment secrets on keysend after adding MPP support, if we sent a secret in this test it would probably pass before this PR (and ofc either way this better tests the actual keysend flow; the fact that we catch the secret case here is more a byproduct of being a better test). So yea this looks good (and maybe should also apply to the MPP keysend tests too)

@TheBlueMatt
Copy link
Collaborator Author

and maybe should also apply to the MPP keysend tests too

It maybe should, but doing it on the MPP tests is annoying since it would mean being much more verbose and doing commitment_signed_dances like 4 times. Because we do check for the preimage in do_pass_along_path (today) I'm gonna just merge as-is and call it a day.

@TheBlueMatt TheBlueMatt merged commit 7e3de70 into lightningdevkit:main Aug 9, 2023
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.

5 participants