In this commit, a migration is done that takes all the AckedUpdates of
all sessions and stores them in the RangeIndex pattern instead and
deletes the session's old AckedUpdates bucket. All the logic in the code
is also updates in order to write and read from this new structure.
In this commit, the code for migration 4 is added. This migration takes
all the existing session acked updates and migrates them to be stored in
the RangeIndex form instead. Note that this migration is not activated
in this commit. This is done in a follow up commit in order to keep this
one smaller.
In this commit, we add the ability to add a wtdb version migration that
does not get given a transaction but rather a whole db object. This will
be useful for migrations that are best done in multiple transaction in
order to use less RAM.
In preparation for an upcoming commit where some helper functions will
need access to the ClientDB's ackedRangeIndex member, this commit
converts those helper functions into methods on the ClientDB struct.
Refactor the putClientSessionBody to take in a session sub-bucket rather
than the top-level session bucket. This is mainly to make an upcoming
commit diff easier to parse.
In this commit, a new concept called a RangeIndex is introduced. It
provides an efficient way to keep track of numbers added to a set by
keeping track of various ranges instead of individual numbers.
Notably, it also provides a way to map the contents & diffs applied to
the in memory RangeIndex (which uses a sorted array structure) to a
persisted KV structure.
In this commit, a new channel-ID index is added to the tower client db
with the help of a migration. This index holds a mapping from a
db-assigned-ID (a uint64 encoded using BigSize encoding) to real channel
ID (32 bytes). This mapping will help us save space in future when
persisting references to channels.
In this commit a migration of the tower client db is done. The migration
creates a new top-level cChanDetailsBkt bucket and for each channel
found in the old cChanSummaryBkt bucket, it creates a new sub-bucket. In
the subbucket, the ClientChanSummary is then stored under the
cChannelSummary key. The reason for this migration is that it will be
useful in future when we want to store more easily accessible data under
a specific client ID.
To avoid the problem where multiple jobs try to create the same cache
entry, we add the GitHub job ID to the cache key.
The two restore keys make it possible that a job can also restore a
cache entry from another job if none for the current job exist yet.
With this commit we allow the Go version that is set up to be
configurable and not dependent on a specific environment variable. This
will allow us to eventually extract the action into a tooling
repository.
For some reason we used to override the GOCACHE and GOPATH variables
earlier. This now causes the updated cache action not to pick up any
caches. As the overrides shouldn't be needed anymore, we remove them.
Add the ability to specify messages < CustomRangeStart that will still
be treated like custom messages by lnd (rather than unknown ones). This
allows code external to lnd to handle protocol messages that are *not
yet known to lnd*.
Our OpenChannelRPC was accepting invalid values for the closing address
field. If we were able to decode the address we would use it in the
script even if the address is for another bitcoin net.
Fixes a bug where channel update data is read until the end of the stream
rather than stopping after the specified length. This is problematic
when failure message tlv data is present, because this data is interpreted
as channel update tlv data.
This commit, the error returned from `getInitialFwdingPolicy` is checked
in order to avoid a nil pointer dereference panic during the
TestFundingManagerCustomChannelParameters test.
In this commit, we modify our gossip broadcast logic to ensure that we
always will send out our own gossip messages regardless of the
filtering/feature policies of the peer.
Before this commit, it was possible that when we went to broadcast an
announcement, none of our peers actually had us as a syncer peer (lnd
terminology). In this case, the FilterGossipMsg function wouldn't do
anything, as they don't have an active timestamp filter set. When we go
to them merge the syncer map, we'd add all these peers we didn't send
to, meaning we would skip them when it came to broadcast time.
In this commit, we now split things into two phases: we'll broadcast
_our_ own announcements to all our peers, but then do the normal
filtering and chunking for the announcements we got from a remote peer.
Fixes https://github.com/lightningnetwork/lnd/issues/6531
Fixes https://github.com/lightningnetwork/lnd/issues/7223
Fixes https://github.com/lightningnetwork/lnd/issues/7073
We start with a simple Map function that can be useful for transforming
objects on the fly.
We may want to eventually make this Taro pakage into a module so we can
just have everything in one place:
https://github.com/lightninglabs/taro/tree/main/chanutils.
