-
Notifications
You must be signed in to change notification settings - Fork 339
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
Don't remove nodes if there's no channel_update for a temp failure #2220
Don't remove nodes if there's no channel_update for a temp failure #2220
Conversation
9a7ef43
to
95ec48a
Compare
Codecov ReportPatch coverage:
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #2220 +/- ##
==========================================
- Coverage 91.57% 91.56% -0.02%
==========================================
Files 104 104
Lines 51553 51559 +6
Branches 51553 51559 +6
==========================================
- Hits 47212 47210 -2
- Misses 4341 4349 +8
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. |
88d0345
to
a22227b
Compare
Went ahead and squashed the fixups:
|
There's a stray call to the previous method name in fuzzing |
a22227b
to
4e36714
Compare
Previously, we were requiring any `UPDATE` onion errors to include a `channel_update`, as the spec mandates[1]. If we see an onion error which is missing one we treat it as a misbehaving node that isn't behaving according to the spec and simply remove the node. Sadly, it appears at least some versions of CLN are such nodes, and opt to not include `channel_update` at all if they're returning a `temporary_channel_failure`. This causes us to completely remove CLN nodes from our graph after they fail to forward our HTLC. While CLN is violating the spec here, there's not a lot of reason to not allow it, so we go ahead and do so here, treating it simply as any other failure by letting the scorer handle it. [1] The spec says `Please note that the channel_update field is mandatory in messages whose failure_code includes the UPDATE flag` however doesn't repeat it in the requirements section so its not crazy that someone missed it when implementing.
4e36714
to
67ad6c4
Compare
Fixed two stray refs:
|
Previously, we were requiring any
UPDATE
onion errors to include achannel_update
, as the spec mandates[1]. If we see an onion error which is missing one we treat it as a misbehaving node that isn't behaving according to the spec and simply remove the node.Sadly, it appears at least some versions of CLN are such nodes, and opt to not include
channel_update
at all if they're returning atemporary_channel_failure
. This causes us to completely remove CLN nodes from our graph after they fail to forward our HTLC.While CLN is violating the spec here, there's not a lot of reason to not allow it, so we go ahead and do so here, treating it simply as any other failure by letting the scorer handle it.
[1] The spec says
Please note that the channel_update field is mandatory in messages whose failure_code includes the UPDATE flag
however doesn't repeat it in the requirements section so its not crazy that someone missed it when implementing.