-
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: interceptor watchdog #6831
htlcswitch: interceptor watchdog #6831
Conversation
65b783c
to
58317fe
Compare
58317fe
to
6c9c4c0
Compare
6c9c4c0
to
04131bd
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.
looks good, have one comment
04131bd
to
7c8035a
Compare
7547a6f
to
1361a5b
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.
Nice to see this change come in! I think it would be a nice addition to surface the height that htlcs will be auto-released on the interceptor api so that calling code can be mindful of that height.
1361a5b
to
0183b31
Compare
979c782
to
4c39d78
Compare
@Crypt-iQ do you want to assign a second Lightning Labs reviewer to this? |
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.
Sorry for the delay on looking a this, looks good now.
I do still think that we should surface the "release height" on the interceptor rpc so that callers know when their htlcs are going to be dropped. Otherwise you need to configure your code with something like --lnd.interceptordelta=x
, which will be incorrect if LND changes its defaults/the value is made configurable. Can be done in a follow up, but I think it's important to make this feature more user-friendly.
4c39d78
to
2aa7095
Compare
Yes, agreed that adding a height to the interceptor request rpc message is useful. Even just during development. Added. |
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 use another reviewer, not because we need LL reviewers, but because we're dealing with switch-related code and it can be tricky
I think this just needs a rebase then it can land. |
2aa7095
to
2be79bc
Compare
Rebased |
@yyforyongyu: review reminder |
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.
Overall looks good. Left several nits and a question about using panic
. I think one day we'll need to unify block consumption in one place.
@@ -3754,9 +3754,22 @@ func assertOutgoingLinkReceiveIntercepted(t *testing.T, | |||
} | |||
} | |||
|
|||
func TestSwitchHoldForward(t *testing.T) { | |||
t.Parallel() | |||
type interceptableSwitchTestContext struct { |
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.
don't quite get the idea behind this test context, looks like in the end it will hold everything.
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 goal is to make the test context and methods operating within the context re-usable for the unit test that is added in the next commit.
// be greater than CltvRejectDelta, because we don't want to offer htlcs | ||
// to the interceptor client for which there is no time left to resolve | ||
// them anymore. | ||
DefaultCltvInterceptDelta = DefaultFinalCltvRejectDelta + 3 |
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.
What's the reason behind 3?
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.
Looked like a reasonable interval for an htlc interceptor application to respond. Suppose there would be three blocks in quick succession - 10 sec/block - the application still has 30 seconds to process the intercept.
d17f1d0
to
c1007cc
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🎉 Thanks for adding the tests!
c1007cc
to
156918d
Compare
GitHub shows a conflict, but doesn't say in which file... Can you try rebasing please? |
Preparation for adding more config options.
Preparation for making the interceptable switch aware of expiring htlcs.
Isolation of the set logic so that it will be easier to add watchdog functionality later.
Refactor to prepare for adding more tests.
Prepares for parameter validation.
156918d
to
b9dd50e
Compare
Done. Problem was the release notes. |
Make the interceptable switch aware of htlc expiry and fail back htlcs in-time to prevent the counterparty from force-closing the channel.
b9dd50e
to
a0a50fa
Compare
Fixes a left-over of the htlc interception api implementation that prevents channels from force-closing if a connected interceptor client does not resolve or resume an htlc in time.
Original mention: #6212 (review)