Wait to free the holding cell during channel_reestablish handling - #1859

Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged

Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe

Conversation

@TheBlueMatt

@TheBlueMattTheBlueMatt commented Nov 17, 2022

Copy link
Copy Markdown
Collaborator

When we process a channel_reestablish message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in get_and_clear_pending_msg_events. This
leaves the in-channel_reestablish holding cell clear redundant,
as doing it immediately or is get_and_clear_pending_msg_events is
not a user-visible difference.

Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.

@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed the 2022-11-rm-redundant-holding-cell-wipe branch from 755f15c to f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter

codecov-commenter commented Nov 17, 2022•
edited
Loading

Copy link
Copy Markdown

Codecov Report

Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉

Coverage data is based on head (f1c6cd8) compared to base (7269fa2).
Patch coverage: 81.66% of modified lines in pull request are covered.

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

Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️

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 at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

valentinewallace
valentinewallace reviewed Nov 21, 2022
View reviewed changes

@valentinewallacevalentinewallace left a comment

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.

Otherwise LGTM I think

Comment threadlightning/src/ln/channelmanager.rs Outdated
@TheBlueMattTheBlueMatt mentioned this pull request Nov 21, 2022
Merged
@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace approved these changes Nov 21, 2022
View reviewed changes

@valentinewallacevalentinewallace left a comment

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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year

@TheBlueMatt
TheBlueMatt merged commit 8245128 into lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees

No one assigned

Labels

Seeking Code Review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace
, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace

, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace

, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace

, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace

, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace

, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace

, '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
Wait to free the holding cell during channel_reestablish handling - #1859
Merged
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Nov 22, 2022
Merged
Wait to free the holding cell during channel_reestablish handling#1859
TheBlueMatt merged 4 commits into
lightningdevkit:mainfrom 
TheBlueMatt:2022-11-rm-redundant-holding-cell-wipe
Conversation
@TheBlueMatt
@TheBlueMattTheBlueMatt
commented
Nov 17, 2022

Copy link


Copy Markdown

Collaborator
When we process a channel_reestablish message we free the HTLC

update holding cell as things may have changed while we were

disconnected. However, some time ago, to handle freeing from the

holding cell when a monitor update completes, we added a holding

cell freeing check in get_and_clear_pending_msg_events. This

leaves the in-channel_reestablish holding cell clear redundant,

as doing it immediately or is get_and_clear_pending_msg_events is

not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
handle_chan_restoration_locked while we're at it.
@TheBlueMatt
Remove log assertions in chanmon_update_fail_tests
c8c0997
Asserting that specific log entries were printed isn't all that
useful, we should really be focusing on the expected messages (or,
when a monitor udpate fails, the lack thereof). In the next commit
one of these log checks would otherwise break due to the particular
time a monitor update fails changing, but I also plan on reworking
the montior update flows substantially soon, breaking lots of them.
@TheBlueMatt
Wait to free the holding cell during channel_reestablish handling
7e9b88a
When we process a `channel_reestablish` message we free the HTLC
update holding cell as things may have changed while we were
disconnected. However, some time ago, to handle freeing from the
holding cell when a monitor update completes, we added a holding
cell freeing check in `get_and_clear_pending_msg_events`. This
leaves the in-`channel_reestablish` holding cell clear redundant,
as doing it immediately or is `get_and_clear_pending_msg_events` is
not a user-visible difference.
Thus, we remove the redundant code here, substantially simplifying
`handle_chan_restoration_locked` while we're at it.
@TheBlueMatt
Convert the handle_chan_restoration_locked macro to a function
f1c6cd8
There is no reason anymore for `handle_chan_restoration_locked` to
be a macro, and our long-term desire is to move away from macros as
they substantially bloat our compilation time (and binary size).
Thus, we simply remove `handle_chan_restoration_locked` here and
turn it into a function.
@TheBlueMatt
TheBlueMattforce-pushed
the
2022-11-rm-redundant-holding-cell-wipe
branch
from
755f15c to
f1c6cd8CompareNovember 17, 2022 17:57
@codecov-commenter
codecov-commenter
commented
Nov 17, 2022•

edited

Loading

Copy link


Copy Markdown

Codecov Report
Base: 90.61% // Head: 90.70% // Increases project coverage by +0.09% 🎉
Coverage data is based on head (f1c6cd8) compared to base (7269fa2).

Patch coverage: 81.66% of modified lines in pull request are covered.
❗ Current head f1c6cd8 differs from pull request most recent head e82cfa7. Consider uploading reports for the commit e82cfa7 to get more accurate results
Additional details and impacted files
@@ Coverage Diff @@## main #1859 +/- ##
==========================================
+ Coverage 90.61% 90.70% +0.09% 
==========================================
Files 90 90 Lines 47623 47552 -71 Branches 47623 47552 -71 ==========================================
- Hits 43152 43132 -20 + Misses 4471 4420 -51 
Impacted FilesCoverage Δ
lightning/src/ln/functional_test_utils.rs93.64% <ø> (ø)
lightning/src/ln/channelmanager.rs86.19% <76.74%> (+1.15%)⬆️
lightning/src/ln/channel.rs88.83% <88.88%> (+0.08%)⬆️
lightning/src/ln/chanmon_update_fail_tests.rs97.58% <100.00%> (-0.03%)⬇️
lightning/src/ln/reload_tests.rs95.24% <100.00%> (ø)
lightning/src/ln/functional_tests.rs97.06% <0.00%> (-0.10%)⬇️
lightning/src/chain/onchaintx.rs94.23% <0.00%> (+0.21%)⬆️
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 at Codecov.

📢 Do you have feedback about the report comment? Let us know in this issue.
valentinewallace
valentinewallace
reviewed
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Otherwise LGTM I think
Comment threadlightning/src/ln/channelmanager.rs
Outdated

@TheBlueMattTheBlueMatt
mentioned this pull request
Nov 21, 2022
 Merged

@TheBlueMatt
Remove the post_handle_chan_restoration macro
e82cfa7
Now that `handle_channel_resumption` can't fail, the error handling
in `post_handle_chan_restoration` is now dead code. Removing it
makes `post_handle_chan_restoration` only a single block, so here
we simply remove the macro and inline the single block into the two
places the macro was used.
valentinewallace
valentinewallace
approved these changes
Nov 21, 2022
View reviewed changes
@valentinewallacevalentinewallace
left a comment


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.

Between this Screen Shot 2022-11-21 at 2 32 07 PM and getting rid of a confusing macro, candidate for PR of the year
@TheBlueMatt
TheBlueMatt
merged commit 8245128
into
lightningdevkit:mainNov 22, 2022
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers

@wpaulinowpaulinowpaulino approved these changes
@valentinewallacevalentinewallacevalentinewallace approved these changes

Assignees


No one assigned


Labels

Seeking Code Review

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

4 participants

@TheBlueMatt@codecov-commenter@wpaulino@valentinewallace