lightninglabs
[bug]: The function `getChannelCustomData` returns the first asset from the first asset channel and does not accept a specific asset to get the data for
The function getChannelCustomData (https://github.com/lightninglabs/lightning-terminal/blob/64ab73a763af01674857a6328dc1b57cf9578352/itest/assets_test.go#L581-L623) returns the first asset (https://github.com/lightninglabs/lightning-terminal/blob/64ab73a763af01674857a6328dc1b57cf9578352/itest/assets_test.go#L621) from the first asset channel (https://github.com/lightninglabs/lightning-terminal/blob/64ab73a763af01674857a6328dc1b57cf9578352/itest/assets_test.go#L607C2-L607C12) and does not accept a specific asset to get the data for. It also errors if there are more than one asset in a channel or more than one asset channel.
getChannelCustomData should be smart enough to accept and asset to look for and return the right asset and not just pick the first one (and only allow a single one). The way it is currently designed, it is not going to work for channels with multiple assets in them. We don't currently have channels with multiple assets types in the same channel (https://github.com/lightninglabs/taproot-assets/issues/1276), but we definitely could want to have multiple asset channels in a single node.
Related, but would it be simpler to implement this if we used a map instead of an slice here: https://github.com/lightninglabs/taproot-assets/blob/4852be495676014f72f1a8267bdb46fb191695fe/rfqmsg/custom_channel_data.go#L39-L45 ?
This will be refactored quite a bit with the ongoing group key channel support.
Has been refactored to meet the needs of grouped channels. If more flexibility is required, then it can be changed in a PR that requires it.
https://github.com/lightninglabs/lightning-terminal/blob/090bdc2cf2bc46c62857e8e8e813ae1bfc9ad87b/itest/assets_test.go#L1116-L1157
still returns the first channel and errors if there is more than one channel.
It now returns all assets instead of the first asset or a specific asset, so I guess that part is better.