-
Notifications
You must be signed in to change notification settings - Fork 224
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
feat: Lightning Client NG Pay Invoice #2279
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #2279 /- ##
==========================================
- Coverage 57.46% 56.16% -1.30%
==========================================
Files 163 167 4
Lines 33738 34551 813
==========================================
Hits 19386 19405 19
- Misses 14352 15146 794
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great progress! Just a few high-level comments about the API, will go through the actual state machines more thoroughly tomorrow :)
The CLI commands all worked for me 🎉 |
a4014fe
to
6eeb381
Compare
old_state: LightningPayStateMachine, | ||
contract_id: ContractId, | ||
) -> LightningPayStateMachine { | ||
// TODO: Retry contacting gateway |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't implement this yet. What do we want the policy to be here? Try 5 times then go to Refundable
? Try forever until we contact the gateway?
let rejected_common = funded_common.clone(); | ||
let success_context = global_context.clone(); | ||
let reject_context = global_context.clone(); | ||
let gateway = self.gateway.clone(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For simplicity's sake while implementing this I just cloned everything. I don't think that's too expensive but its probably not necessary.
6eeb381
to
73abac3
Compare
73abac3
to
8337930
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, some nits but it works and we can improve incrementally
|
||
// Wait for the refund transaction to complete after a lightning invoice | ||
// failed to be paid. | ||
async fn await_lightning_refund( | ||
&self, | ||
operation_id: OperationId, | ||
refund_txid: TransactionId, | ||
) -> anyhow::Result<()>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just wait for the transaction to be accepted? I know I have to add a "await output finalization" function to the PrimaryModule
API, but that doesn't seem high prio since just awaiting tx acceptance is sufficient to guarantee we will get the refund eventually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is just a quirk with the CLI that I pinged you about offline. The CLI just needs to be alive long enough for the output to be finalized so the notes can be retrieved. The Pay
state machine doesn't actually wait on this, it just waits for the refund tx to be accepted then exits. We can refactor this if needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see, was missing that context. I'll implement an abstraction that removes the dependency on the mint module, but good to go for now.
Refunded(TransactionId), | ||
Failure(TransactionId), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could remove these and instead query tx acceptance in LnClientExt::subscribe_ln_pay_updates
, a lot like I did here (definitely not your fault, the API for that just became available 😆 we can patch it out later):
fedimint/modules/fedimint-mint-client/src/lib.rs
Lines 291 to 315 in 4d53190
Ok(Box::pin(stream! { | |
yield SpendOOBState::Created; | |
let refund = refund_future.await; | |
if refund.user_triggered { | |
yield SpendOOBState::UserCanceledProcessing; | |
match tx_subscription.await_tx_accepted(refund.transaction_id).await { | |
Ok(()) => { | |
yield SpendOOBState::UserCanceledSuccess; | |
}, | |
Err(()) => { | |
yield SpendOOBState::UserCanceledFailure; | |
} | |
} | |
} else { | |
match tx_subscription.await_tx_accepted(refund.transaction_id).await { | |
Ok(()) => { | |
yield SpendOOBState::Refunded; | |
}, | |
Err(()) => { | |
yield SpendOOBState::Success; | |
} | |
} | |
} | |
})) |
gateway: LightningGateway, | ||
) -> LightningPayStateMachine { | ||
assert!(matches!( | ||
old_state.state, | ||
LightningPayStates::CreatedOutgoingLnContract(_) | ||
)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you were using the data from inside old_state.state
you wouldn't need to pass in the gateway, potentially saving some clones.
8337930
to
909b087
Compare
909b087
to
acc5a9b
Compare
Lightning Client NG paying a bolt 11 invoice. Adds the
Pay
state machine.