-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
htlcswitch: add htlc interceptor failure control #6177
htlcswitch: add htlc interceptor failure control #6177
Conversation
e67c7c8
to
44a3467
Compare
the |
Yes that is indeed the use case. The htlc interceptor is basically a 'link-over-grpc'. |
44a3467
to
7112669
Compare
That's great, I think this is a superior approach to #4785 |
7112669
to
e328acd
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.
Love this, makes the interceptor way more useful.
lnrpc/routerrpc/router.proto
Outdated
bytes failure_reason = 4; | ||
|
||
// Return UpdateFailMalformedHTLC in case the resolve action is Fail. | ||
MalformedHtlcCode failure_malformed_htlc = 5; |
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.
why did you choose to scope this to malformed htlc errors? As written, it would be easy to add other cases like CodeChannelDisabled
, CodeTemporaryChannelFailure
, CodePermanentChannelFailure
which would be useful too.
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 all that I needed for my purpose. It could be generalized, but then also all the failure message parameters need to be marshaled over rpc? Or would you do a hybrid where you only specify the code and lnd tries to fill in the message parameters?
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.
The ones I was thinking about are either very similar to existing cases or have no parameters. In any case, none of this needs to be implemented now. I was mostly wondering why the thight scope for the semantics.
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.
Reworked the PR to widen the scope.
c251faa
to
7284033
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.
Great addition to the interceptor!
e345400
to
3ba4f33
Compare
@joostjager, remember to re-request review from reviewers when ready |
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, just a few nits 👍
df1dad5
to
db41e72
Compare
db41e72
to
e2b56f2
Compare
code = lnwire.CodeInvalidOnionVersion | ||
|
||
// Default to TemporaryChannelFailure. | ||
case 0, lnrpc.Failure_TEMPORARY_CHANNEL_FAILURE: |
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.
Interesting way to override the default here programatically...🤔
This PR extends the HTLC interceptor API so that users can control the exact failure message that is returned to the sender of the payment.