Because the health check uses OS specific syscalls for determining the
available space on a disk that aren't available in JS/WASM builds, we
need to make sure we don't reference that code at all. Otherwise we
can't use parts of lnd as a library in projects that are being compiled
down to a WASM binary.
Since bbolt uses syscalls for memory mapping that aren't available in
JS/WASM builds, we need to make sure we don't reference that code at
all. Otherwise we can't use parts of lnd as a library in projects that
are being compiled down to a WASM binary.
We only want to register the bbolt DB backend ("bdb") when we're not
compiling for a JS/WASM build targets. That's why we want to have that
import in only one file that we can add a build tag to. We remove it in
two other places since only one import is enough anyway.
This changes file reation mode on admin macaroon from 0600 to 0640. The
reason is to make permission management easier.
Closes#4385
**Is this safe?**
Yes, it is. Assuming a reasonably secure Linux system, it will have a
separate group for each user. E.g. a new user `lnd` gets assigned group
`lnd` which nothing else belongs to. A system that does not do this is
inherently broken already.
Since there is no other user in the group, no other user can read admin
macaroon unless the administrator explicitly allowed it. Thus there's no
harm allowing group read.
The bucket sequence we use as payment sequence makes the DB update in
InitPayment conflict and therefore queue up when many concurrent
payments happen. This change allocates payment sequences in blocks
of 1000 to avoid these conflicts.
Without this commit, the build may break if a PR commit is created, as
that shows the `PR_NUMBER` field we parse out as "master", reflecting
that its a merge commit into the master branch.
The golang version always needs to be in sync between the go.mod, the PR
checklist and the installation instructions.
We also shorten the Pull Request template by removing everything that we
have a CI check for and just refer to those checks instead.
In this commit, we add a simple bash script to parse out the current PR
number from an environment variable in the GH actions context, and use
that to check to see if the PR has been referenced in the release notes
or not. This isn't 100% fool proof, but it should catch most of the
common cases.
This commit removes an assertion which is not needed because with etcd
we can safely create keys and values with the same key since they are
stored under different keys in the DB. This saves us one unnecessary Get
on every Put.
The etcd cursor Delete stepped to the next item in the range before
Delete to not invalidate the iteation. This is unnecessary and not
compatible with bbolt, resulting in an extra fetch too.
In this commit, we attempt to fix a race condition that may occur in the
current AMP and MPP tests.
It appears the following scenario is possible:
* The `mppTestContext` [is used to create 6 channels back to
back](https://github.com/lightningnetwork/lnd/blob/master/lntest/itest/lnd_amp_test.go#L43)
* The method used to create the channel ends up calling
[`openChannelAndAssert`](edd4152682/lntest/itest/lnd_mpp_test.go (L300))
which'll open the channel, mine 6 blocks, [then ensure that the
channel gets
advertised](edd4152682/lntest/itest/assertions.go (L78))
* Later on, [we wait for all nodes to hear about all channels on the
network
level](https://github.com/lightningnetwork/lnd/blob/master/lntest/itest/lnd_amp_test.go#L62)
I think the issue here is that we'll potentially already have mined 30
or so blocks before getting to the final nodes, and those nodes may have
already heard about the channel already. This may then cause their
[`lightningNetworkWatcher`](edd4152682/lntest/node.go (L1213))
goroutine to not properly dispatch this, since it's assumed that the
channel hasn't been announced (or notified) when the method is called.
One solution here is to just check if the channel is already in the
node's graph or not, when we go to register the notification. If we do
this in the same state machine as the watcher, then we ensure if the
channel is already known, the client is immediately notified. One thing
that can help us debug this more in the future is adding additional
logging in some of these helper goroutines so we can more easily track
the control flow.
This commit implements this solution by checking to ensure that the
channel isn't already known in our channel graph before attempting to
wait for its notification, as we may already have missed the
notification before this registration request came in.
This commit creates the file lnd_misc_test.go to hold all miscellaneous
tests in the file lnd_test.go. From now on, the lnd_test.go will only be
responsible for handling the "top" level functionalities such as
splitting test cases and run them. Newly created test cases should find
their places in the related test files, or create new one when needed.
