This commit ensures that we start with the alias, node color,
addresses, and features as advertised in the node's previous
runtime. This approach maintains consistency in the node's
advertised information across restarts.
This commit moves most of the code into its own package. It is
the smallest code move possible without moving import cycles and
keeping the changes to the code base as small as possible during
refactor.
This error is returned when one attempts to use taproot overlay channels
without the necessary auxiliary funding controller being supplied. In
practice, when running lnd via litd, the latter will always supply
'tapd' as the aux funding controller, but a standalone lnd has no
knowledge of that.
The previous message sort of reads like the lnd user has forgotten to
set some available option or flag, but nothing or the sort actually
exists. The update makes it clearer that the feature isn't available in
the standalone build.
We also addd this new db on the server level to use it in the
following commit to do all the payment related queries of the
rpcserver.
We add a new payment db instance on the server level. Which we
will you for the payment related queries in a following commit.
In the following commits we will gradually unify the current
payment db operations into an interface to later down the road
support both backends (sql+kv).
In this commit, we complete the integration of the configurable gossip
filter concurrency by wiring the new FilterConcurrency configuration
through all layers of the application.
The changes connect the gossip.filter-concurrency configuration option
from the command-line interface through the server initialization code
to the gossiper and sync manager. This ensures that operators can
actually use the new configuration option to tune their node's
concurrent gossip filter processing capacity based on their specific
requirements and available resources.
This commit makes removes the `defaultQuiescenceTimeout` and makes it
configurable as different nodes have different network environment. In
addition the default timeout has been increased from 30s to 60s.
On startup, we currently blindly overwrite our node announcement info
for our source node. This includes overwriting the existing LastUpdate
timestamp. This can cause an issue with our new SQL backends in the case
that the new timestamp is not greater than the previously written
timestamp. So here, we first fetch the source node and make sure to use
a timestamp that is greater than the previosly set one.
Replace all usages of the "github.com/go-errors/errors" and
"github.com/pkg/errors" packages with the standard lib's "errors"
package. This ensures that error wrapping and `errors.Is` checks will
work as expected.
We already set `nobootstrap` in the default node flags for itest nodes,
so we can remove this check now. This will allow us to later test
bootstrapping in an itest. NOTE that with this change, any
signet/simnet/regtest network users will now need to explicitly add the
`--nobootstrap` flag if they want to prevent automatic bootstrapping.
This warning is added to the release notes later on.
If there's an error occured when updating the peer's status after the
channel status is changed, we now make sure we log the error instead of
letting it interrupt the channel open/close flow.
For outbound connections, since they are initialized by the users, we
can relax on the restriction. A future global limit may be added - as
for now, we will let them to be managed by the users.
When the callback is called in `scheduledPeerConnection`, it is
referencing the old `access` variable which was created when the peer
was first connected. However, if this peer opens a channel with us and
goes offline, or another inbound connection is made from this peer, we
may still use the old `access` value. To fix it, we need to make sure we
always get the fresh perm by calling `assignPeerPerms` inside
`peerConnected`.
In this commit, we prevent partial mutation of current
node announcement during announcement signing. If node
announcement signing failed the current node announcement
becomes inconsistent.
Since we have not removed all call-sites that make use of this
parameter, we can remove it. This helps hide DB-specific details from
the interface we will introduce for the graph store.
