Fix what `bolt2_open_channel_sending_node_checks_part1` tests by TheBlueMatt · Pull Request #1317 · lightningdevkit/rust-lightning

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt · 2022-02-17T19:46:06Z

This is split out from #1311.

There are currently two issues with
bolt2_open_channel_sending_node_checks_part1 which counteract
each other and hide that the test isn't testing what it should be.

First of all, the final create_channel call actually fails
because we try to open a channel with ourselves, instead of
panicing as the test is supposed to check for.

However, when we fix the create_channel call to panic, when we
drop nodes[1] after create_channel panics, we fail the
no-pending-messages test as it as an expeted accept_channel in
its outbound buffer. This causes a double-panic.

Previously, these two offset each other - instead of panicing in
create_channel we'd panic in the Node drop checks.

This fixes both by fetching the accept_channel before we go into
the panic'ing create_channel call (who's arguments were
corrected).

codecov-commenter · 2022-02-17T20:09:36Z

Codecov Report

Merging #1317 (6e776d9) into main (6259e7a) will increase coverage by 0.07%.
The diff coverage is 100.00%.

@@ Coverage Diff @@## main #1317 +/- ##
==========================================
+ Coverage 90.60% 90.68% +0.07% 
==========================================
Files 72 72 Lines 40075 41412 +1337 ==========================================
+ Hits 36310 37553 +1243 - Misses 3765 3859 +94

Impacted Files	Coverage Δ
lightning/src/ln/functional_tests.rs	`97.10% <100.00%> (-0.04%)`	⬇️
lightning/src/ln/onion_route_tests.rs	`97.62% <100.00%> (ø)`
lightning/src/util/test_utils.rs	`82.42% <100.00%> (-0.02%)`	⬇️
lightning/src/routing/scoring.rs	`95.31% <0.00%> (+0.27%)`	⬆️
lightning/src/ln/channelmanager.rs	`86.15% <0.00%> (+1.45%)`	⬆️

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 6259e7a...6e776d9. Read the comment docs.

TheBlueMatt · 2022-03-04T21:32:43Z

Took a commit to address #1311 (comment)

There are currently two issues with `bolt2_open_channel_sending_node_checks_part1` which counteract each other and hide that the test isn't testing what it should be. First of all, the final `create_channel` call actually fails because we try to open a channel with ourselves, instead of panicing as the test is supposed to check for. However, when we fix the create_channel call to panic, when we drop `nodes[1]` after `create_channel` panics, we fail the no-pending-messages test as it as an expeted `accept_channel` in its outbound buffer. This causes a double-panic. Previously, these two offset each other - instead of panicing in `create_channel` we'd panic in the Node drop checks. This fixes both by fetching the `accept_channel` before we go into the panic'ing `create_channel` call (who's arguments were corrected).

Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt · 2022-03-04T21:58:41Z

Rebased to update upstream changes which were broken by this change.

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

TheBlueMatt added the Seeking Code Review label Feb 18, 2022

valentinewallace previously approved these changes Feb 22, 2022
View reviewed changes

jkczyz self-requested a review March 3, 2022 21:14

TheBlueMatt mentioned this pull request Mar 4, 2022
Support for SCID Aliases #1311
Merged

TheBlueMatt dismissed valentinewallace’s stale review via 9c6a377March 4, 2022 21:32

TheBlueMatt added 2 commits March 4, 2022 21:54

Clean up TestKeysInterface random bytes override interface
6e776d9
Its very confusing to have multiple fields that do the same thing, one of which isn't even used for its stated purpose anymore after the previous few commits.

TheBlueMatt force-pushed the 2022-02-fix-bunk-test branch from 9c6a377 to 6e776d9Compare March 4, 2022 21:54

jkczyz approved these changes Mar 4, 2022
View reviewed changes

valentinewallace approved these changes Mar 4, 2022
View reviewed changes

TheBlueMatt merged commit 0e0aabe into lightningdevkit:mainMar 5, 2022

Uh oh!

Conversation

TheBlueMatt commented Feb 17, 2022

Uh oh!

codecov-commenter commented Feb 17, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Feb 17, 2022

Uh oh!

codecov-commenter commented Feb 17, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Feb 17, 2022

Uh oh!

codecov-commenter commented Feb 17, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

TheBlueMatt commented Feb 17, 2022

Uh oh!

codecov-commenter commented Feb 17, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

TheBlueMatt commented Mar 4, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

codecov-commenter commented Feb 17, 2022•
edited
Loading

codecov-commenter commented Feb 17, 2022•
edited
Loading

codecov-commenter commented Feb 17, 2022•
edited
Loading

codecov-commenter commented Feb 17, 2022•
edited
Loading

codecov-commenter commented Feb 17, 2022•
edited
Loading

codecov-commenter commented Feb 17, 2022•
edited
Loading