Fix input sanitation for listchaintxns lncli cmd

[kornpow]

Change Description

This PR was based originally on the PR #7496 and issue #7316. Upon rebasing and looking at the solutions there, I found the bigger problem with the command was the lack of error messaging when the end_height < start_height rather than the necessity to support a "reverse ordering" feature.

In this PR, I added additional checks to the block height input arguments which prevents providing arguments which get passed down the stack which yields incorrect results.

For example:

end_height < start_height
OR
start_height < 0

This is my first code commit to LND, 2nd including a comment update, so I appreciate the help to getting this PR mergable!

Steps to Test

Try using different options for start_height and end_height, including them, not including them, and having integer values in a way which doesn't make sense, and ensure that the proper errors are shown.

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 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.

[coderabbitai]

Important

Review skipped

Auto reviews are limited to specific labels.

🏷️ Labels to auto review (1)

• llm-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[guggero]

Thanks for the fix. Makes sense, I think the "will be queried in reverse" was probably from an earlier version of the PR that added the offset.

[kornpow]

"will be queried in reverse"

This wording has been there for a long time, and its what inspired the original issue/PR, even before the offset PR. But now we fixed the help text, we don't have to implement it.

[kornpow]

@guggero I would like to potentially add a test for this, but I am not really sure where? Maybe there isnt tests for these kinds of things.

[guggero]

@guggero I would like to potentially add a test for this, but I am not really sure where? Maybe there isnt tests for these kinds of things.

You could extract the argument parsing into a function, then write a unit test for that in cmd/commands/commands_test.go.

The other approach would be an integration test that executes the binary directly. See

lnd/itest/config.go

Line 14 in 64c660c

func testDebuglevelShow(ht *lntest.HarnessTest) {

[lightninglabs-deploy]

@guggero: review reminder

[guggero]

!lightninglabs-deploy mute

[kornpow]

I have added a test with a decent number of test cases.

I also modified the listchaintxns command to formalize that the default case value for end_height=-1. This part confused me a bit when reading through the code, since things "seem to work" when end_height is left unset, which used to give it a default value of 0. However, I think setting it to a default is better.

Finally, as much as I would like to remove the cli context from the test itself, since it makes the test code a decent bit more verbose, I think it is necessary because of testing the behavior like in the paragraph above, where there are certain values unset in the CLI. Also I think it is good because it could provide an example for others how to test the CLI.

Please let me know if you would like me to improve the test structure. I potentially could make the inputs inside a loop and reusing variables, but there is funkiness there with redefining values in flag which I'd have to tackle.

[kornpow]

Been running my new test like this:
env GOEXPERIMENT=loopvar go test -tags="dev autopilotrpc chainrpc invoicesrpc neutrinorpc peersrpc routerrpc signrpc verrpc walletrpc watchtowerrpc wtclientrpc nolog" github.com/lightningnetwork/lnd/cmd/commands -v -run "TestInputListChainTxns"

[MPins]

Good job for your first PR 👍

I ran the test and it’s working — maybe just a few small adjustments are needed.

[kornpow]

I also made a commit with some changes to the help text of the command. It feels like too much of the Flag Usage is finding its way into the Description. Its also really redundant trying to get across the end_height=-1 concept. Let me know if that is out of scope.

[MPins]

Great progress! 👍

I’d suggest squashing the commits into two: one for the doc release and one for the other files — what do you think?

https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#ideal-git-commit-structure

[kornpow]

Great progress! 👍

I’d suggest squashing the commits into two: one for the doc release and one for the other files — what do you think?

https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#ideal-git-commit-structure

Sounds good. Squashed to 2 commits. Getting better at managing the commit history, but still learning where to split the commits. Getting closer I hope!

[MPins]

Some final comments and LGTM! 👍

It would be a good idea to have some description on commit message. Something like:

commands: add a parsing block height function
Added parseBlockHeightInputs function to parse start_height and end_height
from the CLI, ensuring start_height is non-negative and not greater than
end_height (unless it's -1), returning both values and any validation error.

[kornpow]

rebased to fix a merge conflict and to improve commit message.

[MPins]

rebased to fix a merge conflict and to improve commit message.

You should leave just one of the following lines in the commit message:

cmd: Modified listchaintxns command

commands: add a parsing block height function

Maybe the first is better 😉

[kornpow]

rebased to fix a merge conflict and to improve commit message.

You should leave just one of the following lines in the commit message:

cmd: Modified listchaintxns command

commands: add a parsing block height function

Maybe the first is better 😉

Rebased again onto master, and modified the commit message... Hopefully acceptable now.

Its been hard to get all of the integration tests to always pass consistently? I don't think it is related to my changes though? Please let me know.

[guggero]

Thanks for the updates. Getting closer.

[kornpow]

Picture of the new help text, to get a feel for how it looks in-situ