We test both the happy path (valid memo is returned when querying),
as well as the unhappy path (invalid memo rejects the open action).
To accomplish this, we update the OpenChannelParams struct inside
the harness to accept the Memo.
We add a Memo field to the OpenChannel DB struct. We also persist
it using a tlv record. We then pass the Memo value from the
InitFundingReserveMsg when creating a new reservation for the channel.
Finally, we also read Memo field when fetching channel from DB.
This commit simply adds a new memo flag to the openchannel command.
Memo could be any note-to-self kind of useful information to go
along with the channel. The value isn't used yet, will be in the
next commit.
In this commit, we add an Identifier method to the blob.Type struct
which returns a unique identifier for a given blob type. This identifier
is then used for initialising the disk overflow queue of the given
client.
The bug manifests when a nil ChannelType is passed to the funding
manager in InitFundingMsg. A default value for ChannelType is selected
and sent in the OpenChannel message. However, a nil ChannelType is
stored in the reservation context. This causes our ChannelType checks in
handleFundingAccept to be bypassed.
Usually this makes us end up in the "peer unexpectedly sent explicit
ChannelType" case, where we can still recover by reselecting a default
ChannelType and verifying it matches the one the peer sent. But if the
peer sends a nil ChannelType, we miss it.
While fixing the bug, I also tried to simplify the negotiation logic, as
the complexity is likely what hid the bug in the first place.
Now negotiateCommitmentType only returns the ChannelType to be used in
OpenChannel/AcceptChannel and the CommitmentType to pass to the wallet.
It will even return a nil ChannelType when we're supposed to use implicit
negotiation, so we don't need to manually set it to nil for OpenChannel
and AcceptChannel.
This commits uses TestStoreChangePassword to demonstrate that currently
the ChangePassword function only changes the password of the default
root key and not that of other root keys. This will be fixed in an
upcoming commit.
With this commit, GenerateNewRootKey will regenerate the Default root
key and will then also check if any other root keys exist and regenerate
those as well.
This commit adds to the existing TestStoreGenerateNewRootKey to show
that the method only successfully regenerates the root key in the
default root key ID location. This will be fixed in an upcoming commit.
In this commit, a new generic DiskOverflowQueue implementation is added.
This allows a user to specify a maximum number of items that the queue
can hold in-memory. Any new items will then overflow to disk. The
producer and consumer of the queue items will interact with the queue
just like a normal in-memory queue.
This commit adds a test to the wtclient. The test demonstrates that if a
client tries to back up states while it has no active sessions with a
server then those updates are accumlated in memory and lost on restart.
This will be fixed in upcoming commits.
