lnd: use persisted node announcement settings across restarts

[Abdulkbk]

trafficstars

closes #7123

replaces #8690

Change Description

This change allows a node to retain its previously configured node announcement settings after a restart, making it more consistent.

Issue: As mentioned in the issue description:

If you set your alias using the UpdateNodeAnnouncement RPC call it will only maintain this as an update until a restart. Restarting clears all of the node announcement settings.

This creates additional work for users; for instance, if you have a list of addresses you associated with your node using the updatenodeannouncement RPC, you need to set them again each time your node restarts.

This also applies to all fields that can be updated using the updatenodeannouncement RPC, including: alias, color, addresses, and feature bit.

Solution: This update checks for existing node announcement settings and reuses them during startup.

Since the node announcement settings can be set either through the node's config (specified in lnd.conf or passed as command line args) or using the updatenodeannouncement RPC, the hierarchy of precedence for these settings is as follows:

• We check for what's set in config (args or lnd.conf)
• We check for persistent settings (from graphDB)
• We resolve to defaults

Steps to Test

• Install LND with the peersrpc tag: make install tags="peersrpc".

Test for precedence:

1. Set one of the fields in the lnd.conf file, for example, alias=alice.
2. Start LND and update the alias by running: lncli peers updatenodeannouncement -alias=bob.
3. Verify that the alias has been updated using the lncli getinfo command.
4. Restart LND, then run lncli getinfo again to confirm that the alias is now set to alice.

Test for persistence

1. Start LND without configuring one of the fields in the lnd.conf file.
2. Use the command lncli peers updatenodeannouncement -color=#000000 to update the node's color, and verify the change by running lncli getinfo.
3. Restart LND, and then execute lncli getinfo again to ensure that the color value remains the same after the restart.

Alternatively*

make build-itest # to build itest

make make itest-only  icase="node announcement persistence" # to run only the integration test

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[bot]]

[!IMPORTANT]

Review skipped

Auto reviews are limited to specific labels.

:label: 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.
  • Explain this complex logic.
  • 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 explain this code block.
  • @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 explain its main purpose.
  • @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.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

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 generate sequence diagram to generate a sequence diagram of the changes in 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.

[Abdulkbk]

@ellemouton, this pull request replaces #8690 as per your suggestion here. Please review when you have time. Thanks

[ellemouton]

@Abdulkbk - thanks! Although I think you could have just updated the commits in the original PR - no need for a new PR :)

[Abdulkbk]

@Abdulkbk - thanks! Although I think you could have just updated the commits in the original PR - no need for a new PR :)

At first, I thought about doing that, but then I ended up creating a new PR. Thanks for the feedback; I'm really learning a lot.

[Abdulkbk]

Hi @alexbosworth, I've opened this PR to fix the issue #7123 you reported. Could you spare some time to review it? Your input will help me improve the solution.

[Abdulkbk]

Also I think this needs a release note? Maybe add here: https://github.com/lightningnetwork/lnd/blob/7065b6462edf48f3c86a58f2fd215cb0db2c0474/docs/release-notes/release-notes-0.18.1.md

Since this PR persists whatever was previously updated with the updatenodeannouncement lncli command, it means I should add a bullet point to explain that, right? @Chinwendu20

[Chinwendu20]

I think you can add a bullet point to talk about what the change actually is and maybe a short explanation. Maybe under functional updates

[Abdulkbk]

I think you can add a bullet point to talk about what the change actually is and maybe a short explanation. Maybe under functional updates

I just noticed that the issue this PR is addressing is under milestone 0.19.0. Shouldn't the milestone version and release notes version be the same?

[Chinwendu20]

I think it makes sense that it should be the same.

[Abdulkbk]

Hi @yyforyongyu , I noticed that you are one of the code owners of netann. This PR touches nodeannouncement, which I think falls under that. Would you mind reviewing it? It is required before I can get the tests to run.

[Abdulkbk]

Could you help approve the CI, @yyforyongyu?

[Abdulkbk]

Hey @yyforyongyu, I considered adding a test for this change, but since it involves restarting LND, I'm unsure where to begin. Would you happen to have any pointers? Thank you.

[yyforyongyu]

Restarting a node in the itest can be done in multiple ways,

for instance you can suspend a node and restart it later, https://github.com/lightningnetwork/lnd/blob/a388c1f39d849005b58eae81516b4104929101a6/itest/lnd_channel_backup_test.go#L797

or just restart it, https://github.com/lightningnetwork/lnd/blob/a388c1f39d849005b58eae81516b4104929101a6/itest/lnd_misc_test.go#L209

[Abdulkbk]

Restarting a node in the itest can be done in multiple ways,

for instance you can suspend a node and restart it later,

https://github.com/lightningnetwork/lnd/blob/a388c1f39d849005b58eae81516b4104929101a6/itest/lnd_channel_backup_test.go#L797

or just restart it,

https://github.com/lightningnetwork/lnd/blob/a388c1f39d849005b58eae81516b4104929101a6/itest/lnd_misc_test.go#L209

Thanks for the pointers 👍

[lightninglabs-deploy]

@yyforyongyu: review reminder @chinwendu20: review reminder @abdulkbk, remember to re-request review from reviewers when ready

[yyforyongyu]

!lightninglabs-deploy mute

[Abdulkbk]

Hmmm can't seem to figure out why the entire itests keep failing, will need to dig in a little deeper...

[guggero]

Carol fails to start back up:

    --- FAIL: TestLightningNetworkDaemon/tranche00/02-of-297/btcd/route_blinding_dummy_hops (57.55s)
        harness_node.go:403: Starting node (name=Alice) with PID=5933
        harness_node.go:403: Starting node (name=Bob) with PID=6045
        harness_node.go:403: Starting node (name=carol) with PID=6090
        harness_node.go:403: Starting node (name=dave) with PID=6150
        harness_node.go:403: Starting node (name=carol) with PID=6498
        harness.go:568: 
            	Error Trace:	/home/runner/work/lnd/lnd/lntest/harness.go:568
            	            				/home/runner/work/lnd/lnd/lntest/harness.go:607
            	            				/home/runner/work/lnd/lnd/itest/lnd_route_blinding_test.go:1138
            	            				/home/runner/work/lnd/lnd/lntest/harness.go:303
            	            				/home/runner/work/lnd/lnd/itest/lnd_test.go:130
            	Error:      	Received unexpected error:
            	            	ConnectRPC err: context deadline exceeded
            	Test:       	TestLightningNetworkDaemon/tranche00/02-of-297/btcd/route_blinding_dummy_hops
            	Messages:   	failed to restart node carol

With the following error in Carol's log:

unable to create server: can't unset feature bit 25 (route-blinding): feature is used in standard protocol set

[Abdulkbk]

With the following error in Carol's log:

unable to create server: can't unset feature bit 25 (route-blinding): feature is used in standard protocol set

Thanks for pointing that out. This made me realize I could download and view a particular node's logs from the CI, very helpful.

I was initially updating the feature manager with the feature sets that were persisted in the previous run, something like:

        prevFeatures := map[feature.Set]*lnwire.RawFeatureVector{
		feature.SetNodeAnn: sourceNode.Features.RawFeatureVector,
	}
	err = s.featureMgr.UpdateFeatureSets(prevFeatures)
	if err != nil {
		srvrLog.Errorf("unable to update feature sets: %v", err)

		return err
	}

This ensures that when you add an unknown feature bit (2, for example) before restarting, you get to see it in lncli getinfo response even after a restart.

...
 "2":  {
            "name":  "unknown",
            "is_required":  true,
            "is_known":  false
        },
...

The issue arises when we start a node carol in this case with --protocol.no-route-blinding and later restart it with route blinding support, as is done in the itest here, the initial implementation will try to unset the feature bit (since it was not used in the last run).

[Abdulkbk]

@saubyk could you add this to the review board?