The --profile flag now accepts both a port and a host:port string.
If profile is set to a port, then pprof debugging information will
be served over localhost. Otherwise, we will attempt to serve pprof
information on the specified host:port (if we are allowed to listen
on it.)
We default to the safe option as if the port is connectable, anybody
can connect and see debugging information.
See: https://mmcloughlin.com/posts/your-pprof-is-showing
Since zombie pruning can be very slow on some devices (e.g. mobile) it
would stall lnd startup. Since it is not essential for pruning to be
finished for lnd to be functional, we instead delay the initial prune by
30 seconds.
Note that we could also wait for the graphPruneInterval to tick, but
since this is by default 2 hours, it is unlikely that a mobile app will
ever be open that long.
This commit deprecates/replaces the old field `sat_per_byte` with
`sat_per_vbyte`. While the old field suggests sat per byte, it’s
actually using sat per virtual byte. We use the Hidden param to hide all
the deprecated flags. These flags won't show up in help menu onwards,
while stay valid that can be passed from cli. Thus bash scripts
referencing these fields won't be broken.
In this commit, we update to the latest version of neutrino that
includes some GC/perf optimizations when syncing, an exposed block
cache, and also additional filter verification for downloaded filters.
Previously, we would always allow dependent jobs to be processed,
regardless of the result of its parent job's validation. This isn't
correct, as a parent job contains actions necessary to successfully
process a dependent job. A prime example of this can be found within the
AuthenticatedGossiper, where an incoming channel announcement and update
are both processed, but if the channel announcement job fails to
complete, then the gossiper is unable to properly validate the update.
This commit aims to address this by preventing the dependent jobs to
run.
This PR was created in order to help to debug the failures in:
https://github.com/lightningnetwork/lnd/issues/5113
We add some more contextual errors so we can figure out where the
assumptions of the current scan to delete function in the invoice
registry is incorrect.
This commit fixes the following potential deadlock situation:
* Pathfinding holds a database lock and tries to obtain a mission control lock
via GetProbability
* ReportPaymentSuccess/ReportPaymentFail holds a mission control lock
and tries to obtain a database lock to store the payment result.