Related to #4839?
The API at https://api.lightning.community/#addinvoice lists payment_addr as an input (and output). Based on a quick chat with @alexbosworth this seems to be wrong, and should not be considered an input.
Pleae investigate, and remove this from the API, if applicable.
We use the same proto for the response as well as the request, this is why it shows up in both places. There're other fields that are only populated in the response that aren't meant to be populated in the request as well. We can definitely improve documentation on this front.
If removing it as an input is not an option, I agree that proper documentation would also help. As a consumer of the API, without having a good understanding of LND internals, the current state is rather confusing.
Alternatively, we could consider creating an AddInvoiceReq proto. afaik reusing the same protos for request + response isn't the best practice since it leads to situations where fields can't be added/omitted on one end as needs evolve. This would be a breaking change for clients from the perspective of the struct name, but we could make them align at the byte level for the relevant fields. If we don't like that approach there is also the route of adding an AddInvoice2 like we did for SendPayment
I'd go for separate request and response proto's. More flexible and future proof.
Most helpful comment
Alternatively, we could consider creating an
AddInvoiceReqproto. afaik reusing the same protos for request + response isn't the best practice since it leads to situations where fields can't be added/omitted on one end as needs evolve. This would be a breaking change for clients from the perspective of the struct name, but we could make them align at the byte level for the relevant fields. If we don't like that approach there is also the route of adding anAddInvoice2like we did forSendPayment