Fixes#5927.
This commit moves the code that attempts to create parent directories to
the correct place _after_ we've adjusted all path values to point to the
correct places. Before this commit the macaroon and tor paths would
point to their default locations, even if the --lnddir flag was
specified.
Fixes#5936.
This commit makes sure every error that causes the Main() function to
return is logged to the log file in addition to being printed to stderr.
With this commit we standardize the error messages in the config parsing
section of the main package. We only print to stdout/stderr in a single
place and also make sure the same error is printed to the log (which
might or might not yet be initialized at that point).
This commit adds a unique request ID that is the same for each gRPC
request and response intercept message or each request/response message
of a gRPC stream.
This commit adds a new unique intercept message ID that is different for
each message sent to an RPC middleware. This will allow us to re-purpose
the existing request ID field into its original intention, which was to
have a unique ID for a full gRPC request/response pair or gRPC stream as
a whole.
It may happen that we do pathfinding while also attempt to change the
graph. In this case changing the database, channel state, graph while
reading from the same sources may create deadlocks. To resolve this we
change locking policy in the graph cache when pathfinding.
Unfortunately, we can't use the graph cache directly here as it doesn't
include all the information we need, since it only includes the minimal
amount of information needed for path finding.
Instead, we use a simple mutex guarded cache that evicts itself after a
certain interval. The default is set small enough that most users
shouldn't really notice. We also provide a way to disable the cache, and
also disable the cache in the itests.
Fixes https://github.com/lightningnetwork/lnd/issues/1232
This commit, adds a new ForEachNode method to the channel graph cache
that assumes the contents won't be modified. This is generally useful,
and will be used in a later commit to optimize some heavy RPC calls.
Turns out we need it right now to handle some low latency race
conditions in our integration tests, so we'll opt to simply cap the size
of it to a low amount. We use a basic LRU caching mechainsm.
Fixes https://github.com/lightningnetwork/lnd/issues/5076
It looks like in some cases (apparently mostly on Windows) a previous
sub test sometimes leaves some unconfirmed balance in the wallet. That
balance is confirmed in the next test when new coins are sent to the
wallet.
It looks like in some cases a channel is still being closed while we
already try to create a sweep output. In that case the pending closed
channel is still counted as anchor channel and a reserve output is
created. To make sure that doesn't happen, we make sure there are no
pending or open channels of any kind around before we create the sweep
transaction.
