routerrpc: add outgoing_chan_ids to EstimateRouteFee

[asheswook]

Change Description

I needed the OutgoingChanIds field in EstateRouteFee. Fortunately, I was able to change it with a few modifications without core logic changes.

Steps to Test

I didn't write a separate test because this change doesn't change the test coverage of the core route logic.
I checked that the test for the EstimateRouteFee command already exists.

So I added integration tests for outgoing_chan_ids in EstimateRouteFee.

• Estimation with a specific outgoing channel restriction
• Error handling when an invalid channel ID is specified
• Passed make itest icase=estimate_route_fee

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

• The change is not insubstantial. Typo fixes are not accepted to fight bot spam.
• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.
• Any new lncli commands have appropriate tags in the comments for the rpc in the proto file.
• There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

[gemini-code-assist]

Summary of Changes

Hello @asheswook, 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 introduces a new outgoing_chan_ids parameter to the EstimateRouteFee RPC, allowing users to explicitly define a set of channels to be considered for the initial hop of a payment route. This enhancement provides finer-grained control over route fee estimations, making it possible to tailor calculations based on specific channel preferences, thereby improving the accuracy and utility of the fee estimation process for both direct and probe-based routing scenarios.

Highlights

• RPC Enhancement: Added an outgoing_chan_ids field to the EstimateRouteFee RPC request, allowing users to specify preferred outgoing channels for the first hop in fee estimation.
• Command-Line Interface Update: Updated the lncli estimateroutefee command to include a new outgoing_chan_id flag, enabling users to provide a list of desired initial channels.
• Routing Logic Integration: Integrated the new outgoing_chan_ids parameter into both graph-based (probeDestination) and probe-based (probePaymentRequest) route fee calculations, ensuring the specified channels are considered during route restriction.
• API Documentation: Updated the router.proto definition and router.swagger.json to reflect the addition of the outgoing_chan_ids field, ensuring API consistency and discoverability.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

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 pull request 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

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 adds the outgoing_chan_ids field to the EstimateRouteFee RPC, which is a useful addition. The implementation looks correct. However, I have a couple of suggestions. First, for consistency within cmd/commands/cmd_payments.go, the new outgoing_chan_id flag should be a StringSliceFlag and parsed with the existing parseChanIDs helper, similar to other commands. Second, while you've mentioned that core logic is tested, this new functionality should have its own integration test to ensure the outgoing_chan_ids parameter is correctly handled from the CLI/RPC down to the routing logic. Please consider adding a test case to itest/lnd_estimate_route_fee_test.go. The lack of tests for new functionality is a high-severity issue.

[gemini-code-assist]

Code Review

This pull request adds the outgoing_chan_ids field to the EstimateRouteFee RPC, allowing users to specify which outgoing channels to use for fee estimation. The changes look good and include updates to the command-line interface, RPC server, and integration tests. I've made a few suggestions to improve code style and correctness.

[hieblmi]

Thanks for the addition. I think this is useful for calls of Estimate... then PayInvoice, where the invoice payment also uses a outgoing chan id.

Can you resolve the conflicts please.

[asheswook]

Thanks for the addition. I think this is useful for calls of Estimate... then PayInvoice, where the invoice payment also uses a outgoing chan id.

Can you resolve the conflicts please.

@hieblmi I regenerated protobuf file (router.pb.go) and I pushed it.

[hieblmi]

Hi, I have suggestions for some more improvements. Looks almost good to go.

[hieblmi]

lets use a name here like in the other tests, e.g.

failureInsufficientBalance = lnrpc.PaymentFailureReason_FAILURE_REASON_INSUFFICIENT_BALANCE //nolint:ll

[asheswook]

expectedError field is string type, not a FailureReason type. If the path is not found, I think maybe the approach of FailureReason is valid, but if there is no balance, it is correct to treat it as an error.

Instead, as your review, it's better to define the error string value without using it directly like this:

const (
     ErrInsufficientBalance = "insufficient local balance"
)

[asheswook]

@hieblmi Sorry for late. Can you re-review this PR please?

[lightninglabs-deploy]

@hieblmi: review reminder
@asheswook, remember to re-request review from reviewers when ready