Ensure that tests can run in parallel without causing a data race by
adding a `makeTestChannelUpdate` constructor rather than sharing the
same `testChannelUpdate` type between tests. This is needed since some
tests write to the type.
In the graph/db code, we should always expect to deal with potentially
nil ChannelEdgePolicy pointers and so we should always do a nil check
before making use of the struct.
Added flag include_auth_proof to DescribeGraph, GetNodeInfo, GetChanInfo
and the corresponding lncli commands. With the flag, these APIs add AuthProof
(signatures from the channel announcement) to the returned ChannelEdge.
This is useful to extract this data from the DB.
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.
This commit introduces the ResultOpt type, which represents an operation
that can either succeed with an optional final value or fail with an
error.
The .gitignore file is also updated to exclude specific files related to
the `aider` tool.
Here we add the `ForEachNodeDirectedChannel` and `ForEachNodeCacheable`
SQLStore implementations which then lets us run
`TestGraphTraversalCacheable` and `TestGraphCacheForEachNodeChannel`
against SQL backends.
Ensure that it does a sanity check on the length of its input and also
only call it if the nullable SQL string is not null.
Expand an existing unit tests to cover the DecodeHexColor such that it
would have caught the bug.
Use a length check to determine if a bitcoin signature has been set or
not. Also add a clarifying comment to explain why we only need to check
if one signature field is set to determine if we have the auth proof for
the channel or not.
There's no guarantee that the `b.beat` is initialized when the
dispatcher shuts down, especially with the case in the remote signer
where no chainbackend is created.
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`.
When a peer already has a connection with us, there's no need to check
for available slots as we will either close the old conn or refuse the
new conn.
