Adding persistency to neutrino re-scan progress. In case the re-scan
failed in the middle or the node was restarted before the re-scan
has been completed this fix will start from the last point instead
of the beginning.
On long re-scan , such as old channels on mobile devices this is
crucial.
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.
After unification of the WalletUnlocker and RPC services on the same gRPC
server, the WalletUnlocker will no longer be shut down after the wallet
has been unlocked.
In case --no-macaroons was used, this lead to the caller getting stuck
after unlocking the wallet, since we would wait for a response on the
MacResponseChan. Earlier we would close the MacResponseChan always
when shutting down the WalletUnlocker, but this is no longer done.
To fix this we close this channel after the wallet is unlocked,
regardless of which combination of --no-macaroons and --noseedbackup
that is being used.
This commit makes us gate the calls to the RPC servers according to the
current RPC state. This ensures we won't try to call the RPC server
before it has been fully initialized, and that we won't call the
walletUnlocker after the wallet already has been unlocked.
This commit achieves what we have been building up to: running the
WalletUnlockerService and the LightningService on the same gRPC server
simultaneously!
To achieve this, we first create the RPC server in a "interface only"
way, only creating the struct and setting the dependencies we have
available before the wallet has been unlocked. After the wallet has been
unlocked and we have created all the subsystems we need, we add those to
the RPC server, and start the sub-servers.
This means that the WalletUnlockerService and the LightningService both
will be registered and available at all times on the gRPC server.
However, before the wallet has been unlocked, the LightningService
should not be used since the RPC server is not yet ready to handle the
calls. Similarly, after the wallet has been unlocked, the
WalletUnlockerService should not be used. This we will ensure in
following commits.
We don't have to define the external subserver config more than once, so
it is not needed to be defined for every listener. Instead we move it to
the ListenerConfig.
We extract common macaroon validating code into a method, and add a
method whitelist, for methods that won't need macaroons.
This give us explicit control over which methods don't require
macaroons, to avoid inadvertently adding RPCs that are unauthenticated.
For now this whitelist contains the WalletUnlocker methods, as the
wallet password is required to open the macaroon db.
