-
Notifications
You must be signed in to change notification settings - Fork 103
Multi rfq send itest #1097
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
base: master
Are you sure you want to change the base?
Multi rfq send itest #1097
Conversation
6165322
to
c7dbe80
Compare
Seems like you should update to mention the send test, possibly renaming the function name? |
Do we see any value in adding tests where Charlie has more or less channels than Fabia? Like this route seems a bit too simple because both sender and receiver kind of need the same sharding. I'm also wondering if we should test where Charlie-Dave have asset channels and not sats channels. I don't think this test should be removed, but I think there should be some more complex network that tests more than what this test can do in another function. |
c7dbe80
to
32cd575
Compare
1e79938
to
533a39f
Compare
Linter / unit tests fail because of this
which is not related to this PR, the itests should normally run & pass |
The last commit adds a new node to the topology, which always rejects quotes, causing a reliable RFQ negotiation failure this way The tests pass, but they do now expose some potential bug in the RFQ negotiation code where we hang until timeout if the rfq negotiation is not successful. |
Description
Enhances the multi-rfq itest to cover multi-rfq send functionality. In the following topology
we now also get Fabia to pay Charlie back, with amounts that exceed the capacity of each individual channel. We also use a hold invoice to validate that multiple HTLCs were added in different channels.
Related PRs (in order of merge sequence):
lightningnetwork/lnd#9980
lightninglabs/taproot-assets#1613
lightninglabs/loop#968