-
Notifications
You must be signed in to change notification settings - Fork 210
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
refactor: remove subscribe htlcs and complete_htlc #2161
Conversation
c8be000
to
f296b80
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #2161 +/- ##
==========================================
- Coverage 60.09% 60.02% -0.07%
==========================================
Files 152 152
Lines 31054 31263 +209
==========================================
+ Hits 18662 18766 +104
- Misses 12392 12497 +105
... and 18 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ 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.
started a review yesterday but didn't get quite through.
Submitting the comments now anyway hoping that they're not all out of date after the push
0c7f409
to
d065757
Compare
// The index of the incoming htlc in the incoming channel. | ||
uint64 htlc_id = 2; |
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.
Does this abstract well over implementations?
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.
It does not currently, it is specific to LND. Let me see if there's an easy refactor so that it is generalized.
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 changed the gRPC spec to just include the incoming channel id and the htlc id in the SubscribeInterceptHtlcsResponse
. This is generic across all implementations.
In LND we just pass these values onto LND to complete the HTLC. For our CLN implementation, we use it as the key into our outcomes
map to lookup the channel sender needed to unblock the thread that will complete the HTLC.
(Adding @okjodom's comments that he sent offline while he didn't have much internet access) |
d065757
to
53f3c6b
Compare
53f3c6b
to
4e9c2ea
Compare
74a8d9e
to
8591246
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
continue; | ||
Some(route_htlc_response::Action::CompleteResponse(_complete_response)) => { | ||
// TODO: Might need to add some error handling here | ||
info!("Successfully handled HTLC"); |
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.
Might be good to include some information about the HTLC that was handled
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.
Gonna leave this one as a todo since we don't actually know much about this HTLC (CompleteResponse
doesn't contain any data currently).
8591246
to
75b47e3
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.
big change. left some comments and questions but these are better addressed in a new PR as this one is already rather big.
nice work! @m1sterc001guy
(also tested a bit in tmuxinator. seems to work so far 👍)
#[derive(Clone)] | ||
struct LightningSenderStream { | ||
ln_sender: Sender<RouteHtlcRequest>, | ||
lnrpc: Arc<RwLock<dyn ILnRpcClient>>, | ||
} |
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 add a doc string here?
for my understanding: the decision to use a RwLock
instead of a tokio Mutex is that the tokio::RwLock
is write-preferring, right?
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'll add a docstring. My understanding is RwLock is actually read-optimizied since it won't block other readers
// Create a channel that will be used to shutdown the HTLC thread | ||
let (sender, receiver) = mpsc::channel::<Arc<AtomicBool>>(100); |
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 use a one shot channel or do we need to be able to receive the shutdown signal more than once?
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.
This is currently somewhat difficult because GatewayActor
needs to be clonable. After this refactor though I think it should be possible
type HtlcOutcomeSender = oneshot::Sender<serde_json::Value>; | ||
|
||
/// Functional structure to filter intercepted HTLCs into subscription streams. | ||
/// Used as a CLN plugin | ||
#[derive(Clone)] | ||
pub struct ClnHtlcInterceptor { | ||
subscriptions: Arc<Mutex<HashMap<u64, HtlcSubscriptionSender>>>, | ||
pub outcomes: Arc<Mutex<HashMap<sha256::Hash, HtlcOutcomeSender>>>, | ||
pub outcomes: Arc<Mutex<BTreeMap<(u64, u64), HtlcOutcomeSender>>>, |
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.
(u64, u64)
is what exactly? channel_id
and "the index of the incoming htlc in the channel"?hash
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.
Yes. Probably should make a new data structure to encapsulate
for actor in actors.values() { | ||
actor.write().await.subscribe_htlcs().await?; | ||
let (sender, receiver) = mpsc::channel::<Arc<AtomicBool>>(100); |
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.
could this be a oneshot channel, too?
CI audit:
we shouldn't forget about his, either. |
This got fixed here #2204 |
Currently in the gateway, there are two RPCs needed for completing an HTLC:
subscribe_htlcs
andcomplete_htlc
. Subscribe returns a stream which the actors use to determine if they need to take an action with the federation. If the gateway is able to get the preimage, it then callscomplete_htlc
to complete the payment.However, it is not necessary to have two separate RPCs and this makes the code a bit more complicated. This refactor changes it so there is only one RPC called
route_htlcs
. This RPC takes a stream as input and returns a stream. This way, the actors can send messages using the input stream rather than needing to call a separate RPC.This allows us to clean up the code a bit. In the LND implementation, we are able to remove the
outcomes
map.Fixes: #1936