Update litcli for multi-rfq send #1125

GeorgeTsagk · 2025-07-31T15:02:03Z

Description

With the introduction of multi-rfq send we added a new response item in the send payment stream which includes all of the acquired quotes in an array.

This PR updates the RPC client that handles the stream in the context of litcli to correctly read & parse all the possible response items.

gemini-code-assist

Summary of Changes

Hello @GeorgeTsagk, 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 primarily focuses on enhancing the litcli command-line interface to fully support the recently introduced multi-RFQ send functionality. It ensures that the client can correctly interpret and present all relevant quote information received during a payment stream, improving the user experience for asset transfers.

Highlights

Multi-RFQ Send Support: I've updated the litcli RPC client to correctly parse and display multiple accepted RFQ (Request for Quote) sell orders received in a stream, aligning with the new multi-RFQ send feature in taproot-assets.
Stream Processing Refinement: The Recv method within resultStreamWrapper has been refactored to continuously read from the payment stream, handling both individual AcceptedSellOrder messages (for backward compatibility) and the new AcceptedSellOrders array, until the final PaymentResult is received.
Flag Usage Clarification: The usage description for the rfq_peer_pubkey command-line flag has been updated to clarify that it is now truly optional, and if unset, RFQ peers will be automatically selected.

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.

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 updates litcli to handle multiple RFQ quotes from the payment stream. The main change is in the Recv function, which now loops to process different response types, including a new one for a list of quotes.

My review focuses on two points in the new implementation:

A critical regression that could lead to a panic due to a missing check. I've provided a suggestion to fix this.
A potential for duplicate output due to the logic for handling legacy and new quote messages. I've explained the issue and suggested a more robust pattern.

Overall, the change correctly addresses the need to handle multiple quotes, but the identified issues should be addressed to ensure correctness and robustness.

cmd/litcli/ln.go

GeorgeTsagk · 2025-09-29T13:53:49Z

Rebased

ViktorT-11

The code generally locks good 🚀! Though I lack quite a bit of context to fully understand this change, so generally just reviewing from a code perspective.

Leaving a few questions that could or could not be helpful.
Other then the suggestions above, I think it would also be helpful for reviewers if you add more details to the commit message description.

ViktorT-11 · 2025-10-07T11:09:23Z

cmd/litcli/ln.go

+			"quote when converting from assets to sats; if left " +
+			"unset then rfq peers will be picked automatically",


hmmm not seeing that the rest of the changes in this PR actually changes this? If this is due to some other change that's already been merged previously, consider splitting this change into a separate commit and explain why this is now added.

ViktorT-11 · 2025-10-07T11:13:11Z

cmd/litcli/ln.go

+		case *tchrpc.SendPaymentResponse_AcceptedSellOrder:
+			err := printQuote(r.AcceptedSellOrder)
+			if err != nil {
+				return nil, err
+			}

-		return resp.GetPaymentResult(), nil
+			legacyFirstPrint = true

-	case *tchrpc.SendPaymentResponse_PaymentResult:
-		return r.PaymentResult, nil
+		case *tchrpc.SendPaymentResponse_AcceptedSellOrders:
+			quotes := r.AcceptedSellOrders.AcceptedSellOrders

-	default:
-		return nil, fmt.Errorf("unexpected response type: %T", r)
+			for _, quote := range quotes {
+				// If the first item was returned via the legacy
+				// field then skip printing it again here. This
+				// skip only applies to the first element.
+				if legacyFirstPrint {
+					legacyFirstPrint = false
+					continue
+				}
+
+				err := printQuote(quote)
+				if err != nil {
+					return nil, err
+				}
+			}


Just checking that this is correct behaviour:
There is no return statement for the *tchrpc.SendPaymentResponse_AcceptedSellOrder & *tchrpc.SendPaymentResponse_AcceptedSellOrders cases here unless there's no error, meaning that they won't break the for loop without any errors being thrown somewhere in the next loop iteration. Is that correct behaviour?

Yeah great observation. That's actually how the RPC endpoint behaves.

We'll first return any quote-related information, then we'll follow up with the payment result.

ViktorT-11 · 2025-10-07T11:15:47Z

Also, this would need release notes updates, whenever this gets merged to master.

lightninglabs-deploy · 2025-10-14T12:29:51Z

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

With the introduction of multi-rfq send in taproot assets (see related PR lightninglabs/taproot-assets#1613) we extended the behavior of the SendPayment RPC slightly. Now we may not specify an RFQ peer in order for a list of peers to be created & used automatically. When that happens, we will return multiple quotes over the RPC. The content of this commit changes our client wrapper around the handling of the payment result. Previously we'd expect for exactly a single quote to be returned over the stream (for the single defined peer). Now we read all of the quotes that are returned in the new quotes array field of the RPC. To maintain backwards compatibility we also kept the previous single-quote RPC field, which we make sure to only read once now that we read both fields (avoid a duplicate quote from appearing in the logs).

GeorgeTsagk · 2025-10-15T15:24:15Z

With #1155 merged we can now base this off master

darioAnongba

Only nit comments. I have little context on litd so this is just pure code review.

darioAnongba · 2025-10-16T09:03:07Z

cmd/litcli/ln.go


-		// If the calculated number of units is 0 then the asset rate
-		// was not sufficient to represent the value of this payment.
+		// The purpose of this function is just to print, so let's avoid


This should not be a comment in the code (since it references deleted code), it's more like a remark on the PR or a commit description.

darioAnongba · 2025-10-16T09:03:50Z

cmd/litcli/ln.go


 		fmt.Printf("Got quote for %v asset units at %v msat/unit from "+
-			"peer %s with SCID %d\n", numUnits, msatPerUnit,
+			" peer %s with SCID %d\n", numUnits, msatPerUnit,


double space?

Suggested change

" peer %s with SCID %d\n", numUnits, msatPerUnit,

"peer %s with SCID %d\n", numUnits, msatPerUnit,

darioAnongba · 2025-10-16T09:23:02Z

cmd/litcli/ln.go


-			return nil, errors.New("unexpected nil result")
-		}
+		switch r := res.(type) {


Switching over type feels strange to me but I have little context on litd.
I'm surprised we need to differentiate between deprecated AcceptSellOrder and the new AcceptedSellOrders. If the litd version supporting multi-rfq is released after the tapd version that adds the new AcceptedSellOrders, it seems reasonable that litd should simply not support the deprecated type. This is backwards compatibility squared.

Otherwise might be worth adding a comment explaining when the support for legacy can be dropped because there is no direct correlation between dropping support in tapd and litd.

darioAnongba · 2025-10-16T09:37:33Z

docs/release-notes/release-notes-0.16.0.md

 ### Technical and Architectural Updates

 ## RPC Updates
+- [Updated litcli](https://github.com/lightninglabs/lightning-terminal/pull/1125)


The actual impact in litcli could be clearer? Like:

"rfq_peer_pubkey is now optional in all contexts"

or something.

GeorgeTsagk self-assigned this Jul 31, 2025

gemini-code-assist bot reviewed Jul 31, 2025

View reviewed changes

cmd/litcli/ln.go Show resolved Hide resolved

cmd/litcli/ln.go Show resolved Hide resolved

GeorgeTsagk force-pushed the update-cli-multirfq branch from 674cb93 to f2b930d Compare August 1, 2025 09:50

guggero force-pushed the tapd-main-branch branch from d59f943 to 4c6c117 Compare August 18, 2025 15:36

GeorgeTsagk force-pushed the tapd-main-branch branch from 4c6c117 to f76ce2f Compare September 8, 2025 12:49

GeorgeTsagk force-pushed the tapd-main-branch branch from f76ce2f to 712847f Compare September 25, 2025 13:37

GeorgeTsagk force-pushed the update-cli-multirfq branch from f2b930d to 26d9f53 Compare September 29, 2025 13:53

GeorgeTsagk added the no-changelog This PR is does not require a release notes entry label Sep 29, 2025

GeorgeTsagk requested review from ViktorT-11 and darioAnongba October 6, 2025 14:54

ViktorT-11 reviewed Oct 7, 2025

View reviewed changes

GeorgeTsagk force-pushed the tapd-main-branch branch from 24d92f3 to 9787fa1 Compare October 14, 2025 09:41

GeorgeTsagk force-pushed the tapd-main-branch branch from ec3473a to d9b6f4c Compare October 15, 2025 11:46

GeorgeTsagk force-pushed the update-cli-multirfq branch from 26d9f53 to 56df35c Compare October 15, 2025 12:00

GeorgeTsagk requested a review from ViktorT-11 October 15, 2025 12:09

GeorgeTsagk added 2 commits October 15, 2025 14:12

docs: add release note

d009418

GeorgeTsagk force-pushed the update-cli-multirfq branch from 56df35c to d009418 Compare October 15, 2025 12:14

GeorgeTsagk changed the base branch from tapd-main-branch to master October 15, 2025 15:24

darioAnongba approved these changes Oct 16, 2025

View reviewed changes

		"quote when converting from assets to sats; if left " +
		"unset then rfq peers will be picked automatically",

	" peer %s with SCID %d\n", numUnits, msatPerUnit,
	"peer %s with SCID %d\n", numUnits, msatPerUnit,

Update litcli for multi-rfq send #1125

Are you sure you want to change the base?

Update litcli for multi-rfq send #1125

Conversation

GeorgeTsagk commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

GeorgeTsagk commented Sep 29, 2025

Uh oh!

ViktorT-11 left a comment

Choose a reason for hiding this comment

Uh oh!

ViktorT-11 Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

ViktorT-11 Oct 7, 2025

Choose a reason for hiding this comment

Uh oh!

GeorgeTsagk Oct 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ViktorT-11 commented Oct 7, 2025

Uh oh!

lightninglabs-deploy commented Oct 14, 2025

Uh oh!

GeorgeTsagk commented Oct 15, 2025

Uh oh!

darioAnongba left a comment

Choose a reason for hiding this comment

Uh oh!

darioAnongba Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

darioAnongba Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

darioAnongba Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

darioAnongba Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

GeorgeTsagk commented Jul 31, 2025 •

edited

Loading

GeorgeTsagk Oct 15, 2025 •

edited

Loading