New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
multi: accept memo note when opening channel #7668
multi: accept memo note when opening channel #7668
Conversation
Looks like Line 693 in 04314d3
The test seems to pass if I attach a Line 313 in 04314d3
But that shouldn't be required right? Am I doing something wrong with the TLV stream which messes up (de)serialization when the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice feature and well structured PR, thanks a lot!
cd2bea9
to
6692435
Compare
Hey @guggero I updated the PR to address all your feedback:
Also thanks so much for helping with the unit test failure. Your suggestion seems to have worked 馃檪 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of more nits, otherwise LGTM 馃帀
6692435
to
a69bad9
Compare
Hey @guggero addressed all your feedback as well as fixed a silly mistake I made in the itest (used |
Hey @guggero the windows itest check seems to fail because of a process lock on a file it seems? Is that expected? Also any suggestions as to whom I could tag for a second review? |
Yeah, unfortunately some itests are still flaky, we are working on that.
Good question. Looking for volunteers, @ffranr, @positiveblue, @sputn1ck, @bitromortac. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 馃殌
This is such a quick win. I can see a lot of usage form external software that opens channels automatically for example.
I think we should make the UX more coherent by also adding this field to the PendingChannels
proto message but nothing blocking.
rpcserver.go
Outdated
@@ -2169,6 +2169,11 @@ func (r *rpcServer) parseOpenChannelReq(in *lnrpc.OpenChannelRequest, | |||
in.CommitmentType) | |||
} | |||
|
|||
if len(in.Memo) > 500 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: create a constant for this magic number
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: consider adding a comment to explain why the length needs to be limited to 500.
useful information. This is only ever stored locally and in no way impacts | ||
the channel's operation. | ||
*/ | ||
string memo = 36; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we should add the same field to PendingChannels
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will address in a follow-up PR if that's ok. Want to make sure I can handle all cases around pendingopen/pendingforceclose/pendingwaitingclose properly and not inadvertently cause any more regressions in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I enjoyed walking through the commits, nice work!
rpcserver.go
Outdated
@@ -2169,6 +2169,11 @@ func (r *rpcServer) parseOpenChannelReq(in *lnrpc.OpenChannelRequest, | |||
in.CommitmentType) | |||
} | |||
|
|||
if len(in.Memo) > 500 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: consider adding a comment to explain why the length needs to be limited to 500.
// Bob shouldn't see the memo since it's for Alice only. | ||
channel = ht.QueryChannelByChanPoint(bob, chanPoints[0]) | ||
require.Empty(ht, channel.Memo, "Memo is not empty") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
馃憤
This commit adds the memo field to the protobuf message and generates the new go files.
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.
a69bad9
to
ce0d924
Compare
Thanks for the review @positiveblue and @ffranr ! 馃檪 I fixed the one commit message and created a constant for the magic number (along with some comments). I will defer the |
In this commit we ensure that the string length of the memo field specified as part of the OpenChannelRequest is no longer than 500.
We add byte-array field called Memo to the InitFundingMsg struct. We also provide a value for this from rpcserver.go#parseOpenChannelReq().
We also pass the value of Memo from funding/manager.go.
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 allows us the memo to be returned in responses such as listchannels.
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.
ce0d924
to
be82091
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Detailed commit messages 馃憤
Note that I haven't tested.
Thank you folks! My first PR 馃ゲ |
Change Description
Fixes #7639 by allowing a note ("memo") to go along with channel creation when using the openchannel CLI/RPC/JSON command. We accept a string with max length of 500 (command is rejected if length is exceeded) and persist it in a hex-encoded format as part of the TLV stream. When channels are queried, we retrieve the value and decode it before passing the info to the caller. We also add a new itest to verify both the happy and unhappy path.
Steps to Test
When using openchannel through CLI/RPC/JSON, pass in a memo note using the
memo
argument. If length is valid (<= 500), it should persist and be retrievable in listchannels call. If length is invalid, the command should be rejected with an appropriate error message.Pull Request Checklist
Testing
Code Style and Documentation
[skip ci]
in the commit message for small changes.馃摑 Please see our Contribution Guidelines for further guidance.