Find and replace all nolint instances refering to the `lll` linter and
replace with `ll` which is the name of our custom version of the `lll`
linter which can be used to ignore log lines during linting.
The next commit will do the configuration of the custom linter and
disable the default one.
Add this file both to the main LND directory so that devs can use it for
local linter runs and also add it to the `tools` directory so that the
docker environment used to run the linter in CI has access to it. A
custom linter binary can be built via `golangci-lint custom`. This will
pull in and register all the plugins listed in the new config file when
building the new binary. The new binary can then be run using
`custom-gcl run`.
This commit introduces the `LLPlugin` type and converts the existing lll
code such that the LLPlugin implements the register.LinterPlugin
interface. This will allow us to plug it into golangci-linter as a
plugin.
In this commit, we copy the implementation of the golangci-lint lll
linter which we currently use in our CI flow during the `make lint`
check. This commit copies the code mostly as is (the only exception
being the line which trims white space before checking if a line starts
with "import"), and formats it to fit our codebase guidelines. A test is
also added so that we can be sure that the following commits which
adjust the implementation have the intended results.
The custom linter is put into its own module as this is requied by the
`golangci-lint custom` when building the custom linter binary which
includes the plugin.
and the same for ChannelStateDB.FetchChannel. Most of the calls to these
methods provide a `nil` Tx anyways. The only place that currently
provides a non-nil tx is in the `localchans.Manager`. It takes the
transaction provided to the `ForAllOutgoingChannels` callback and passes
it to it's `updateEdge` method. Note, however, that the
`ForAllOutgoingChannels` call is a call to the graph db and the call to
`updateEdge` is a call to the `ChannelStateDB`. There is no reason that
these two calls need to happen under the same transaction as they are
reading from two completely disjoint databases. And so in the effort to
completely split untangle the relationship between the two databases, we
now dont use the same transaction for these two calls.
Before this commit, the `(channeldb.DB).AddrsForNode` method treats the
results from the channel db and the graph db slightly differently. It
errors out if the channel db is unaware of the node in question but does
not error out if the graph is unaware of the node. So this commit
changes the logic slightly so that a "node-unknown" error from either
backing source is not seen as an error.
In this commit, we implement a version of the AddrSource interface which
merges the results of a set of AddrSource implementations. This will
later be used to merge the results of the channel db and graph db.
Our aim is to completely remove the `channeldb.DB`'s direct dependence
on the `graphdb.ChannelGraph` pointer. The only place where it still
depends on this pointer is in the `(DB).AddrsForNode(..)` method where
it queries both the channel DB and the graph db for the known addresses
for the node in question and then combines the results. So, to separate
these out, we will define an AddrsForNodes interface in this commit
which we will later let both the ChannelGraph and channeldb.DB both
implement and we will merge these results outside of the channeldb
package.
All this commit does is to unify the `AddrSource` interface since this
has been defined separately in a couple of places.
We also now use the graph DB's own optional functions. An instance of
the graph is currently still passed to the channeldb's
`CreateWithBackend` function. This will be removed in a later commit
once the two have been completely disjoint.
All the structs defined in the `channeldb/models` package are graph
related. So once we move all the graph CRUD code to the graph package,
it makes sense to have the schema structs there too. So this just moves
the `models` package over to `graph/db/models`.
We have the same helpers for writing and reading a wire.Outpoint type
defined separately in a couple places. We will want to use these from
the graph db package soon though so instead of defining them again
there, this commit unifies things and creates a single exported set of
helpers. The next commit will make use of these.
In preparation for moving the graph related schema structs to the graph
package in an upcoming commit, we move these methods to the graph
package. The structs we will move make use of these methods but we still
import them from channeldb so as to keep the ReadElement and
WriteElement helpers working as they do today.
In this commit, we fix an existing race in the new `protofsm` state
machine executor tests.
The race would appear as such:
```
--- FAIL: TestStateMachineMsgMapper (0.00s)
state_machine_test.go:165:
Error Trace:/home/runner/work/lnd/lnd/protofsm/state_machine_test.go:165
/home/runner/work/lnd/lnd/protofsm/state_machine_test.go:451
Error: Object expected to be of type *protofsm.dummyStateStart, but was *protofsm.dummyStateFin
Test: TestStateMachineMsgMapper
FAIL
FAILgithub.com/lightningnetwork/lnd/protofsm0.116s
FAIL
```
This race condition was triggered as before we would start the state
machine _then_ register for notifications. In `Start` we emit the
starting event, then enter the main loop. If that event gets emitted
before our subscription, then we'll miss the event, as the terminal
event will be the only one received.
We fix this by registering for the events before the daemon has started.
This change simplifies some of the quiescer responsibilities in
favor of making the link check whether or not it has a clean state
to be able to send or receive an stfu. This change was made on the
basis that the only use the quiescer makes of this information is
to assess that it is or is not zero. Further the difficulty of
checking this condition in the link is barely more burdensome than
selecting the proper information to pass to the quiescer anyway.
In this commit we implement a noop quiescer that we will use when
the feature hasn't been negotiated. This will make it far easier to
manage quiescence operations without having a number of if statements
in the link logic.
In this commit we defer processRemoteAdds using a new mechanism on
the quiescer where we capture a closure that needs to be run. We
do this because we need to avoid the scenario where we send back
immediate resolutions to the newly added HTLCs when quiescent as
it is a protocol violation. It is not enough for us to simply defer
sending the messages since the purpose of quiescence itself is to
have well-defined and agreed upon channel state. If, for whatever
reason, the node (or connection) is restarted between when these
hooks are captured and when they are ultimately run, they will
be resolved by the resolveFwdPkgs logic when the link comes back
up.
In a future commit we will explicitly call the quiescer's resume
method when it is OK for htlc traffic to commence.
