Potential Offer Handling #85
Conversation
To allow external callers to shutdown lndk, we provide a shutdown trigger and listener to the onion messenger, replacing the single use channels that we previously used. This is useful for itests, so that we can cleanly shut down and for callers of the library to manage execution.
Provide end user with something to interact with when they want to pay offers.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #85 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 1 1
Lines 12 16 +4
======================================
- Misses 12 16 +4 ☔ View full report in Codecov by Sentry. |
|
@carlaKC Ahh yup this makes sense to me, I think. I'll refactor with this (or something like it) as the base. |
| .await | ||
| .expect("failed to get info") | ||
| .into_inner(); | ||
| pub struct OfferHandler { |
There was a problem hiding this comment.
I'm trying to think through a name that'll encompass that this struct is used both for forwarding onion messages (which might not be related to offers) and handling offer specific message. What about naming this something like... InternalOnionMessenger or OnionHandler so it doesn't conflict with LDK's OnionMessenger?
No rush to reply to this, I know you're on vacation haha. Just want to keep track of some of the questions I have here in the meantime...
|
Closing this out as it was just an example- @orbitalturtle feel free to take this over / squash your changes as needed. |
Opening up to express some ideas around how we'd handle #81 and #84, not intended for merge.
We've already got a lot of the machinery in place to handle the onion messaging side of things in LDK, so I'd like to try to take advantage of that - if we provide an
OfferMessageHandlerthat correctly queues messages, the existing onion messenger will drive sending / notifying of onion messages. That leaves our code responsible for:Hope that this adds some context to the review!