offers: wait for offers invoice #84
Conversation
orbitalturtle
force-pushed
the
wait-for-offers-invoice
branch
4 times, most recently
from
2530ec6 to
815e171
Compare
We fix a typo in the Makefile so it only runs the integration tests instead of all the tests (unit and integration).
We need to send the reply_path along with our invoice request so that the offer creator knows where to reply with the invoice.
orbitalturtle
force-pushed
the
wait-for-offers-invoice
branch
from
815e171 to
a87b987
Compare
| // TODO: Restarting the lnd node here isn't ideal. But for some reason after we call LDK's open_channel | ||
| // API call, LND blocks and is unable to receive any API requests. This might be a bug in ldk-sample or | ||
| // our ldk-sample implementation. | ||
| lnd.handle.kill().expect("lnd couldn't be killed"); |
There was a problem hiding this comment.
Hmmm FYI I found a fix for this -- it seems like the problem has something to do with mining a bunch of blocks while lnd is trying to initiate a channel open. I'll push up a fix for this soon so we can remove this restart.
There was a problem hiding this comment.
Ah that makes sense - some RPC calls will fail if we're not synced to chain. Easiest way will prob be to poll GetInfo to make sure that we're synced?
There was a problem hiding this comment.
Good call, I'll give that a try. Right now I just have some sleeps scattered throughout as a POC, which is definitely not ideal!
There was a problem hiding this comment.
Looking at this and #81, I think we need to think about pulling our our existing OnionMessenger functionality into a dedicated struct where we can rely on what we already have. I know this feels annoying when we're just doing a CLI to start with, but I think we should design this with the possibility of this turning into a server one day / what that would look like in mind. Will try to bang together some code today which explains this thinking a little better.
| match message { | ||
| OffersMessage::Invoice(invoice) => { | ||
| println!("Received an invoice offers message."); | ||
| self.invoices.lock().unwrap().push_back(invoice); |
There was a problem hiding this comment.
Shouldn't we track that we actually sent an invoice request for the offer, and discard the invoice if not?
| @@ -168,12 +169,15 @@ async fn test_lndk_send_invoice_request() { | |||
| client: client_clone.lightning().to_owned(), | |||
| }; | |||
| let blinded_path = offer.paths()[0].clone(); | |||
| let secp_ctx = Secp256k1::new(); | |||
| let reply_path = | |||
| BlindedPath::new_for_message(&[pubkey_2, lnd_pubkey], &messenger_utils, &secp_ctx).unwrap(); | |||
There was a problem hiding this comment.
Should this be included in #81?
|
Closing this in favor of a new incoming PR with #85 as the base :) |
This PR implements the next part of the offers flow, as described in #64.
After sending an invoice request to the offer creator, we wait for an invoice to be returned.
It depends on #81 and the changes in lndk-org/ldk-sample#8