Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update lnd compile-time dependency to v0.19 #1422

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
Open

Update lnd compile-time dependency to v0.19 #1422

wants to merge 13 commits into from

Conversation

guggero
Copy link
Member

@guggero guggero commented Mar 5, 2025

This updates the compile-time dependency of lnd to the current master branch, which will be 0.19 RC1 very soon.
The diff is quite large because of the following major changes in lnd:

  • lnd/fn was updated to lnd/fn/v2 which included some breaking API changes
  • The logging system was updated to github.com/btcsuite/btclog/v2
  • The lnd itest framework removed the standby nodes

NOTE: The LiT integration test is expected to fail for this PR, since this PR is required for litd to update. So we have a circular dependency here.

@coveralls
Copy link

coveralls commented Mar 5, 2025

Pull Request Test Coverage Report for Build 13822880107

Details

  • 0 of 152 (0.0%) changed or added relevant lines in 16 files are covered.
  • 24393 unchanged lines in 168 files lost coverage.
  • Overall coverage decreased (-26.9%) to 27.895%

Changes Missing Coverage Covered Lines Changed/Added Lines %
rfqmsg/accept.go 0 1 0.0%
tapcfg/server.go 0 1 0.0%
chain_bridge.go 0 2 0.0%
itest/tapd_harness.go 0 2 0.0%
rpcserver.go 0 2 0.0%
tapchannel/commitment.go 0 2 0.0%
rfq/stream.go 0 3 0.0%
rfq/manager.go 0 4 0.0%
server.go 0 4 0.0%
rfqmsg/records.go 0 6 0.0%
Files with Coverage Reduction New Missed Lines %
address/mock.go 2 86.93%
asset/witness.go 2 91.38%
proof/util.go 2 81.63%
tapdb/migrations.go 2 74.63%
address/log.go 3 0.0%
commitment/log.go 3 0.0%
internal/pedersen/commitment.go 3 95.31%
rfq/log.go 3 0.0%
tapchannel/aux_leaf_signer.go 3 43.43%
tapchannel/log.go 3 0.0%
Totals Coverage Status
Change from base Build 13795771378: -26.9%
Covered Lines: 25355
Relevant Lines: 90894

💛 - Coveralls

@guggero guggero force-pushed the lnd-19 branch 5 times, most recently from be66843 to 12575eb Compare March 5, 2025 17:58
Copy link
Member

@ellemouton ellemouton left a comment

Choose a reason for hiding this comment

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

LGTM! Thanks for this - huge lift fosho 🙏

Left comments on 2 spots where the logging init can be simplified now that the rotating log writer and std-out logger have been divorced

@@ -569,10 +572,16 @@ func (a *AuxSweeper) createAndSignSweepVpackets(
return lfn.Ok(vPkts)
}

return lfn.AndThen2(
return lfn.FlatMapResult(
Copy link
Member

Choose a reason for hiding this comment

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

nice 🙏 glad we didnt need to do AndThen(AndThen())

Copy link
Member Author

Choose a reason for hiding this comment

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

We kind of had to... Just that AndThen is now called FlatMapResult 😅

Copy link
Member

@GeorgeTsagk GeorgeTsagk left a comment

Choose a reason for hiding this comment

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

LGTM 🍰
seems like we need to do some bump in LiT too?
LiT itest failure log

@ellemouton
Copy link
Member

seems like we need to do some bump in LiT too?

@GeorgeTsagk - see the PR description

@guggero guggero force-pushed the lnd-19 branch 2 times, most recently from 77fe4c2 to 7f57edc Compare March 6, 2025 11:38
@guggero
Copy link
Member Author

guggero commented Mar 6, 2025

Since this will break the lit itest on main when merged, I'm going to leave the PR open until we have at least the branch/PR up in lit, then we can point to that temporarily.

@ellemouton
Copy link
Member

opened this pr against this branch: #1427

@guggero guggero force-pushed the lnd-19 branch 3 times, most recently from 321a9e1 to 8d4b4d0 Compare March 11, 2025 16:37
guggero and others added 10 commits March 11, 2025 16:03
We no longer need our custom action for adding Go module caching, since
that functionality is now included in version 5 of the setup-go action.
We also bump the checkout action to the latest one.
To reduce the size of the diff in the next commit, we update all usages
of the lnd fn package where they are independent from lnd (meaning we
don't use the results to interact with lnd).
Anywhere we interact with lnd, we need to use the same version as lnd,
so we'll need to do it in the next commit where we bump the lnd
dependency.
Currently (*AuxTrafficShaper).ProduceHtlcExtraData exits early if the
htlcCustomRecords are empty. However, we need to cater for the case when
htlc custom records exist from other contexts (such as endorsement
signaling) and so we change this check to be more strict and to check
that the records dont contain any asset records.
Because GetInfo now (lnd 0.19) waits for all subsystems to be synced to
the latest block, we might get into a deadlock situation if we call
GetInfo downstream of an aux component call (which might happen in case
of a force closure):
Observed deadlock case: force closure of custom channel -> lnd detects
force closure during block beat -> calls into aux component to resolve
-> resolution involves registering a transfer in the chain porter ->
chain porter gets CurrentHeight from chain bridge -> chain bridge calls
into lnd's GetInfo -> GetInfo is blocked because the block beat sync is
still waiting for the resolution of the aux channel.

By diverting the call to the chain backend directly, we resolve this
circular dependency.
Until we've merged the litd version bump PR for lnd (which in term
requires this PR to be merged), we resolve the circular dependency by
just pointing to that branch to prove the changes in this PR work.
Because spew.Sdump will iterate through the whole struct, it will also
access maps, such as the underlying sync.Map. Which can then lead to
concurrent map access, because that access isn't protected by the mutex.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 👀 In review
Development

Successfully merging this pull request may close these issues.

4 participants