lnrpc: re-enable custom records#3744
Conversation
|
@cfromknecht, we spoke offline about the risk that we wouldn't be able to deserialize even custom records from our own database as long as odd/even checking was part of the |
f31c80a to
3b5c934
Compare
|
Added the custom range check. Hopefully this PR didn't miss any entry/exit point for custom records. Because of the duplicated send interface, it is quite a few places. |
guggero
left a comment
There was a problem hiding this comment.
Nice to see those custom TLVs enabled again!
My only question is about the documentation comments in the proto file.
There was a problem hiding this comment.
On every other field that has the type bytes involved, we have the following comment:
When using REST, this field must be encoded as base64.
Do we want to add this here too?
There was a problem hiding this comment.
To be consistent with the hop message, I would say this should be renamed to something like dest_custom_records. Comment should also mention custom record range
360b3b7 to
0c6dd92
Compare
77d1038 to
fce2d0d
Compare
fce2d0d to
2e40d5a
Compare
cfromknecht
left a comment
There was a problem hiding this comment.
LGTM, just one small comment about aligning the rpc field names
There was a problem hiding this comment.
To be consistent with the hop message, I would say this should be renamed to something like dest_custom_records. Comment should also mention custom record range
2e40d5a to
17c3576
Compare
This commit also modifies a previous migration. Because the change is so limited, we don't consider this a significant risk.
Remove code duplication in preparation for additional unmarshalling.
This commit also renames the rpc field for consistency. As it wasn't functional and the id doesn't change, this isn't considered a breaking change.
17c3576 to
352334d
Compare
This PR re-enables custom record sending that was disabled in #3575.
It leaves the database serialization format as is, because there currently is no functional need to change it.