Do not force-close channels when we cannot communicate with peers - #1429

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged

Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
TheBlueMatt:2022-04-drop-no-conn-possible

Conversation

@TheBlueMatt

@TheBlueMattTheBlueMatt commented Apr 18, 2022

Copy link
Copy Markdown
Collaborator

In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.

In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.

@TheBlueMatt
TheBlueMattforce-pushed the 2022-04-drop-no-conn-possible branch 3 times, most recently from dba08e5 to 6741021CompareApril 18, 2022 03:02
@codecov-commenter

codecov-commenter commented Apr 18, 2022•
edited
Loading

Copy link
Copy Markdown

Codecov Report

Merging #1429 (62edee5) into main (62edee5) will not change coverage.
The diff coverage is n/a.

❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results

@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.

valentinewallace
valentinewallace reviewed Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/channelmanager.rs Outdated
Comment threadlightning/src/ln/functional_tests.rs
assert_eq!(nodes[1].node.list_channels().len(), 1);
check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);

@valentinewallacevalentinewallaceApr 18, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer

@TheBlueMattTheBlueMattApr 18, 2022

Copy link
Copy Markdown
CollaboratorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.

@valentinewallacevalentinewallaceApr 19, 2022

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431

vincenzopalazzo
vincenzopalazzo previously approved these changes Apr 18, 2022
View reviewed changes

@vincenzopalazzovincenzopalazzo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!

valentinewallace
valentinewallace previously approved these changes Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed the 2022-04-drop-no-conn-possible branch from 72c29ff to 6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt

TheBlueMatt commented Apr 19, 2022

Copy link
Copy Markdown
CollaboratorAuthor

Squashed

valentinewallace
valentinewallace reviewed Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs Outdated
valentinewallace
valentinewallace previously approved these changes Apr 20, 2022
View reviewed changes
@TheBlueMatt

TheBlueMatt commented Apr 20, 2022

Copy link
Copy Markdown
CollaboratorAuthor

Squashed.

@TheBlueMatt
TheBlueMattforce-pushed the 2022-04-drop-no-conn-possible branch from e15c339 to 5033f80CompareApril 20, 2022 15:55
arik-so
arik-so previously approved these changes Apr 27, 2022
View reviewed changes
@TheBlueMatt

TheBlueMatt commented Apr 27, 2022

Copy link
Copy Markdown
CollaboratorAuthor

Oops missed that this now depends on #1435.

@TheBlueMatt
TheBlueMattforce-pushed the 2022-04-drop-no-conn-possible branch from 5033f80 to 99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed the 2022-04-drop-no-conn-possible branch from 99f0855 to e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt

TheBlueMatt commented Apr 28, 2022

Copy link
Copy Markdown
CollaboratorAuthor

Not really sure why this ended up based on #1435, but that landed now so rebased this.

@TheBlueMatt
TheBlueMatt merged commit e5c988e into lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11 mentioned this pull request May 16, 2022
Merged
tnull pushed a commit to tnull/rust-lightning that referenced this pull request May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes
+1 more reviewer
@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Do not force-close channels when we cannot communicate with peers - #1429
Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
May 14, 2022
Merged
Do not force-close channels when we cannot communicate with peers#1429
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom 
TheBlueMatt:2022-04-drop-no-conn-possible
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Apr 18, 2022

Copy link


Copy Markdown

Collaborator
In general, we should never be automatically force-closing our

users' channels unless there is some immediate risk of funds loss

(ie because of some HTLC(s) which are timing out soon). In any

other case, we should trust the user to be able to figure out what

is going on and close their channels manually instead of trying to

be overly clever and automate closures if we think the channel is

useless.
In this case, even if a peer has some required feature that does

not allow us to communicate with them, there is a strong

possibility that some LDK upgrade may allow us to in the future. In

the mean time, there is no reason to go on-chain unless the user

needs funds immediately. In such a case, the user should already

have logic to force-close channels with peers which are not

available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
3 times, most recently
from
dba08e5 to
6741021CompareApril 18, 2022 03:02
@codecov-commenter
codecov-commenter
commented
Apr 18, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Merging #1429 (62edee5) into main (62edee5) will not change coverage.

The diff coverage is n/a.
❗ Current head 62edee5 differs from pull request most recent head e39d63c. Consider uploading reports for the commit e39d63c to get more accurate results
@@ Coverage Diff @@## main #1429 +/- ##
=======================================
Coverage 90.88% 90.88% =======================================
Files 75 75 Lines 41517 41517 Branches 41517 41517 =======================================
Hits 37734 37734 Misses 3783 3783 
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 62edee5...e39d63c. Read the comment docs.
valentinewallace
valentinewallace
reviewed
Apr 18, 2022
View reviewed changes
Comment threadlightning/src/util/events.rs
Outdated

Comment threadlightning/src/ln/peer_handler.rs
Outdated

Comment threadlightning/src/ln/channelmanager.rs
Outdated

Comment threadlightning/src/ln/functional_tests.rs
	assert_eq!(nodes[1].node.list_channels().len(), 1);
	check_closed_event!(nodes[0], 1, ClosureReason::CommitmentTxConfirmed);
	check_closed_event!(nodes[1], 1, ClosureReason::DisconnectedPeer);
	check_closed_event!(nodes[1], 1, ClosureReason::HolderForceClosed);
@valentinewallacevalentinewallaceApr 18, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think after this we we'll be missing test coverage of ClosureReason::DisconnectedPeer
@TheBlueMattTheBlueMattApr 18, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, well this doesn't change coverage of it for the "peer disconnected before confirmation" reason, only the no_connection_possible reason, so it doesn't really change coverage.
@valentinewallacevalentinewallaceApr 19, 2022

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#1431
vincenzopalazzo
vincenzopalazzo
previously approved these changes
Apr 18, 2022
View reviewed changes
@vincenzopalazzovincenzopalazzo
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feature to have!
valentinewallace
valentinewallace
previously approved these changes
Apr 19, 2022
View reviewed changes
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
72c29ff to
6902ccbCompareApril 19, 2022 18:07
@TheBlueMatt
TheBlueMatt
commented
Apr 19, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed
valentinewallace
valentinewallace
reviewed
Apr 19, 2022
View reviewed changes
Comment threadlightning/src/ln/peer_handler.rs
Outdated

valentinewallace
valentinewallace
previously approved these changes
Apr 20, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 20, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Squashed.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
e15c339 to
5033f80CompareApril 20, 2022 15:55
arik-so
arik-so
previously approved these changes
Apr 27, 2022
View reviewed changes
@TheBlueMatt
TheBlueMatt
commented
Apr 27, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Oops missed that this now depends on #1435.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
5033f80 to
99f0855CompareApril 27, 2022 17:43
@TheBlueMatt
Do not force-close channels when we cannot communicate with peers
e39d63c
In general, we should never be automatically force-closing our
users' channels unless there is some immediate risk of funds loss
(ie because of some HTLC(s) which are timing out soon). In any
other case, we should trust the user to be able to figure out what
is going on and close their channels manually instead of trying to
be overly clever and automate closures if we think the channel is
useless.
In this case, even if a peer has some required feature that does
not allow us to communicate with them, there is a strong
possibility that some LDK upgrade may allow us to in the future. In
the mean time, there is no reason to go on-chain unless the user
needs funds immediately. In such a case, the user should already
have logic to force-close channels with peers which are not
available for any reason.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-04-drop-no-conn-possible
branch
from
99f0855 to
e39d63cCompareApril 28, 2022 02:50
@TheBlueMatt
TheBlueMatt
commented
Apr 28, 2022

Copy link


Copy Markdown

CollaboratorAuthor
Not really sure why this ended up based on #1435, but that landed now so rebased this.
@TheBlueMatt
TheBlueMatt
merged commit e5c988e
into
lightningdevkit:mainMay 14, 2022
@ViktorT-11ViktorT-11
mentioned this pull request
May 16, 2022
 Merged

tnull pushed a commit
to tnull/rust-lightning
that referenced
this pull request
May 17, 2022
@TheBlueMatt@tnull
Merge pull requestlightningdevkit#1429from TheBlueMatt/2022-04-drop…
6e2d744
…-no-conn-possible
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@arik-soarik-soarik-so approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

+1 more reviewer

@vincenzopalazzovincenzopalazzovincenzopalazzo left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@arik-soarik-so

Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@TheBlueMatt@codecov-commenter@arik-so@valentinewallace@vincenzopalazzo