[2/3] lnwire: fix encoding customized TLV records

[yyforyongyu]

Similar to #10027 and #10072, we now fix more msgs re the wrong encoding used in the extra data field. A followup PR will complete the fix series.

[gemini-code-assist]

Summary of Changes

Hello @yyforyongyu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue in the lnwire package where customized TLV records within Lightning Network messages were being incorrectly encoded due to mutable ExtraData fields. My changes introduce a more robust and immutable approach to handling these TLV records during both serialization and deserialization. This ensures that messages are consistently and correctly transmitted across the network, improving the reliability of Lightning Network communication. This is part of a series of fixes aimed at rectifying these TLV encoding discrepancies.

Highlights

• Refactored TLV Encoding/Decoding: I've refactored the TLV encoding and decoding logic across several lnwire messages (AcceptChannel, ChannelReady, ChannelReestablish, ChannelUpdate1, ClosingComplete, ClosingSig, ClosingSigned). The primary change ensures that when ExtraData (customized TLV records) is processed, a new TLV stream is constructed for encoding, and known/unknown records are extracted immutably during decoding. This prevents unintended mutations of the original ExtraData field, which was causing incorrect serialization.
• Added Robust Encode/Decode Tests: To thoroughly test these changes and prevent future regressions, I've added new, comprehensive encode/decode roundtrip tests for each affected lnwire message. These tests verify that a message can be encoded, then decoded, and the resulting message's raw byte representation matches the original, even when including various known and unknown TLV records.
• Improved Test Data Generation for TLV: I've introduced new helper functions, RandUnknownRecords and RandExtraRecords, in lnwire/test_utils.go. These functions streamline the generation of random ExtraOpaqueData for testing purposes, allowing us to specify known record types to exclude, ensuring more realistic and targeted test scenarios for TLV handling.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses a bug in TLV record encoding where unknown records in the ExtraData field were not being preserved across encode/decode cycles. The fix is consistently applied across multiple message types (AcceptChannel, ChannelReady, ChannelReestablish, ChannelUpdate1, ClosingComplete, ClosingSig, and ClosingSigned). The new approach correctly extracts known TLV records while preserving unknown ones during decoding, and merges them back together during encoding. The addition of round-trip encode/decode tests for each affected message, which include both known and unknown TLV records, is excellent and ensures the fix is robust. The changes to the testing infrastructure in test_message.go and test_utils.go also improve the quality of property-based tests. The code quality is high and adheres to the repository's style guide. I have no further comments.

[lightninglabs-deploy]

@yyforyongyu, remember to re-request review from reviewers when ready