Fixing the current state update when lncli debuglevel and lncli setmccfg are called

[MPins]

Fixes #8793

modified: rpcserver.go
modified: server.go
modified: routing/missioncontrol.go

Change Description

Changed the DebugLevel function to start updating the main cfg DebugLevel variable.

Created the function UpdateRoutingConfig to just update the main cfg values, this function is a callback function propagated by NewMissionControl function called when creating a new server on server.go. And finally, call the callback function on SetConfig on routing/missioncontrol.go

Steps to Test

After running LND with the wallet unlocked, send the lncli commands to change the debuglevel and estimator and check if they are updated unsing 'getdebuginfo'.

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.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

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>.
  • 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 generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @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 as 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 resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

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]

Nice work @MPins. I left a few comments.

Also, I don't think this commit is necessary since all you did was add comments.

[MPins]

Nice work @MPins. I left a few comments.

Also, I don't think this commit is necessary since all you did was add comments

Thank you! ... About this last comment ... That's weird ... because I've added the line containing 'cfg.UpdateEstimatorValue(cfg.Estimator)' also

[MPins]

Hello everyone, the code is working as expected! But the changes made with lncli setmccfg are not impacting the information we get from lncli getdebuginfo . It looks like the GetDebugInfo function is getting this information from somewhere else.

lnd/rpcserver.go

Line 3164 in 71ba355

func (r *rpcServer) GetDebugInfo(_ context.Context,

[Chinwendu20]

~So GetDebugInfo is getting its info from a different config from the one that you are updating (r.cfg)

lnd/rpcserver.go

Line 3166 in b67af4a

flatConfig, _, err := configToFlatMap(*r.cfg)

You would have to change it to r.server.cfg to get the updated one.

Then maybe change this from r.cfg.LogWriter to r.server.cfg.LogWriter so that all the config updates can be in one place:

lnd/rpcserver.go

Line 6901 in b67af4a

err := build.ParseAndSetDebugLevels(req.LevelSpec, r.cfg.LogWriter)

I think maybe the config field in the rpcserver struct should be removed entirely since we can access config from the server field but I would like hear what other ppl think about it~

Edit:
Please ignore my earlier comments on this, it should work either ways if you are using r.cfg or r.server.cfg as they have same memory address. I think once you fix the pointer thing here it should work #8857 (comment)

[Chinwendu20]

Nice work. I do think the commit does not follow the guidelines:
https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#ideal-git-commit-structure

[alexbosworth]

utconceptack

[guggero]

Can you rebase the PR to get rid of the merge commits please? Then I'll take another look.

[MPins]

Can you rebase the PR to get rid of the merge commits please? Then I'll take another look.

Sorry about that mess! I'm learning a lot of things at the same time and the git collaboration process is one of them!

Rebase done, thank you for pointing it.

[guggero]

Thanks for the rebase. Looks a bit better now.
Unfortunately there's another bit of learning ahead of you. Open Source is quite demanding in terms of git proficiency, since crafting a Pull Request is often as much about the reviewer as it is about the code change itself.
So what you'll want to do to make sure your PRs are getting accepted quickly, is what I call "Review Oriented Programming". Basically you want to tell a coherent story to the reviewer with each commit.

That means each commit should be a small but internally consistent (e.g. each commit compiles on its own) change, with a clear description (e.g. in the commit message or code comments) of why the change is needed and why it's done in this specific way. And each commit should be in a logical order that makes sense to the reviewer.

What you want to avoid is that the commits show different iterations of things you tried or changes during the review itself. So that a new reviewer looking at the code doesn't have to look at all the different stages the code went through and can just take in the current state.

Don't worry if you don't get that perfect for the first couple of pull requests, great commit crafting is a hard skill to learn and an art form in itself.

So long story short: can you please update your PR so it only has 3 or 4 commits? You'll probably want to use interactive rebase to achieve that.

Here are a couple of links that should get you started:

• https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#ideal-git-commit-structure
• https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
• https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d

[MPins]

Thanks for the rebase. Looks a bit better now. Unfortunately there's another bit of learning ahead of you. Open Source is quite demanding in terms of git proficiency, since crafting a Pull Request is often as much about the reviewer as it is about the code change itself. So what you'll want to do to make sure your PRs are getting accepted quickly, is what I call "Review Oriented Programming". Basically you want to tell a coherent story to the reviewer with each commit.

That means each commit should be a small but internally consistent (e.g. each commit compiles on its own) change, with a clear description (e.g. in the commit message or code comments) of why the change is needed and why it's done in this specific way. And each commit should be in a logical order that makes sense to the reviewer.

What you want to avoid is that the commits show different iterations of things you tried or changes during the review itself. So that a new reviewer looking at the code doesn't have to look at all the different stages the code went through and can just take in the current state.

Don't worry if you don't get that perfect for the first couple of pull requests, great commit crafting is a hard skill to learn and an art form in itself.

So long story short: can you please update your PR so it only has 3 or 4 commits? You'll probably want to use interactive rebase to achieve that.

Here are a couple of links that should get you started:

• https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#ideal-git-commit-structure
• https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
• https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d

Thank you very much for investing time in providing such valuable guidance. I'll be working on it today and let you know when ready.

[MPins]

Thanks for the rebase. Looks a bit better now. Unfortunately there's another bit of learning ahead of you. Open Source is quite demanding in terms of git proficiency, since crafting a Pull Request is often as much about the reviewer as it is about the code change itself. So what you'll want to do to make sure your PRs are getting accepted quickly, is what I call "Review Oriented Programming". Basically you want to tell a coherent story to the reviewer with each commit.

That means each commit should be a small but internally consistent (e.g. each commit compiles on its own) change, with a clear description (e.g. in the commit message or code comments) of why the change is needed and why it's done in this specific way. And each commit should be in a logical order that makes sense to the reviewer.

What you want to avoid is that the commits show different iterations of things you tried or changes during the review itself. So that a new reviewer looking at the code doesn't have to look at all the different stages the code went through and can just take in the current state.

Don't worry if you don't get that perfect for the first couple of pull requests, great commit crafting is a hard skill to learn and an art form in itself.

So long story short: can you please update your PR so it only has 3 or 4 commits? You'll probably want to use interactive rebase to achieve that.

Here are a couple of links that should get you started:

• https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#ideal-git-commit-structure
• https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
• https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d

Done ... only 3 commits!

[guggero]

Code and commit structure looks pretty good now! Mostly nits remaining.

[lightninglabs-deploy]

@Abdulkbk: review reminder
@Chinwendu20: review reminder

[Abdulkbk]

LGTM

[ellemouton]

nice work! My main comment is about ensuring that we account for all MC config values here and not just the estimator

[ellemouton]

for call backs, we should not assume that they are necessarily set. So we should do a nil check here before invoking it

[ellemouton]

for example, this commit by itself does not set UpdateEstimator and so this would panic as is

[ellemouton]

or you can avoid the nil check by instead having:

UpdateEstimator fn.Option[func(estimator Estimator)]

and then:

m.cfg.UpdateEstimator.WhenSome(func(f func(estimator Estimator)) {
		f(cfg.Estimator)
})

[MPins]

I'll be addressing the nil check ... thanks!

[MPins]

nice work! My main comment is about ensuring that we account for all MC config values here and not just the estimator

Thank you for your careful review.

[ellemouton]

@MPins - thanks for the quick updates!

I've unresolved one comment cause it is unaddressed:

what about other config values that are not estimator related such as MaxMcHistory and MinFailureRelaxInterval? I think perhaps we should instead make this more generic: OnConfigUpdate?

I didnt just mean the name of the call-back. I meant the actual behaviour too. It should take in the cfg, not just the Estimator. Ie, if I update any MC config values via the rpc, those should be reflected in GetDebugInfo.

This also needs a rebase as there is a merge conflict

[ellemouton]

almost there 🙏

Also just note that 0.18.3 has now shipped so we will need to move the release notes over to a new doc. Currently still unsure if this will be 0.18.4 or 0.19.0. But lets just focus on getting this fully approved first & then we can worry about which doc to put the release notes in :)

[ellemouton]

@MPins can you rebase & add release notes to 0.19 in the mean time so that the CI can run pls 🙏

[MPins]

@MPins can you rebase & add release notes to 0.19 in the mean time so that the CI can run pls 🙏

Thank you. Done.

[ellemouton]

Thanks! 🛠️