[sql-47] Actions migration prep #1126
Conversation
ViktorTigerstrom
added
the
no-changelog
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @ViktorTigerstrom, I'm Gemini Code Assist1! 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 refactors the startup process of litd to prepare for an upcoming actions migration. The primary goal is to establish a connection to LND and fetch necessary macaroons before initializing the application's stores. This reordering is crucial because the macaroons are required during the migration, and they can only be fetched once an LND connection is active. Consequently, the setup of litd's RPC servers, which depend on initialized stores, has also been adjusted to occur later in the startup sequence.
Highlights
- Startup Process Reordering: I've reordered the litd startup sequence in terminal.go to ensure that the connection to LND is established and basic LND client is set up before the application's stores are initialized and RPC servers are created. This allows for fetching LND macaroons earlier in the process.
- Split LND Client Setup: The LND client setup has been split into two distinct phases: setupBasicLNDClient for an early, non-blocking connection to fetch macaroons, and setupFullNDClient (formerly setUpLNDClients) which waits for LND to be fully synced and unlocked, used later in the startup.
- RPC Server Initialization and Registration: The initialization of account and session RPC servers, along with their registration to the RPC proxy, now occurs after the stores are initialized and the basic LND client is connected. A new helper function, registerSubDaemonGrpcServersToProxy, has been introduced to manage this registration explicitly.
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.
Footnotes
-
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. ↩
There was a problem hiding this comment.
Code Review
This PR refactors the startup process of litd to initialize the LND connection before the data stores, which is a prerequisite for an upcoming actions migration. The changes look good and achieve the stated goal. I've found one critical bug related to initialization order that could cause a panic, and a couple of minor typos in comments.
| host, network, tlsPath, macPath, macData := g.cfg.lndConnectParams() | ||
|
|
||
| if g.cfg.LndMode == ModeIntegrated { | ||
| // Ssince we will not require tls when communicating with lnd |
There was a problem hiding this comment.
Typo: "Ssince" should be "Since".
| // Ssince we will not require tls when communicating with lnd | |
| // Since we will not require tls when communicating with lnd |
ViktorTigerstrom
force-pushed
the
2025-08-actions-migration-prep
branch
2 times, most recently
from
af4ea49 to
0d9f96f
Compare
In the upcoming actions migration, we need fetch LNDs macaroons prior to initializing the stores, as the macaroons will be required during the migration. This requires that we setup the connection to LND before we initialize the stores, as we can only fetch the macaroons after the LND connection is established. In preparation of doing so, we cannot reference the stores when initializing/creating the accounts RPC server object, as we do so prior to setting up the LND connection. This commit therefore refactors the accounts RPC server so that we separate the initializing from the starting of the RPC server, and only require the store reference during the actual startup of the RPC server. Note that while this commit adds an `active atomic int32` to the RPC server which must be set toggled before the server will process requests, the RPC proxy and status manager will ensure that no requests get sent to the RPC prior to LiT's subserver being set to running. This is added to ensure that we dont introduce any nil pointer panics in future updates though, as the RPC server would panic in requests were actually processed prior to it having the dependencies injected during the `Start` function. Also note that we still keep the init of the accounts RPC server reference prior to setting up the LND connection, as not doing so would require that we'd refactor the registering of `GrpcSubserver`s in a more complex and in a less elegant way.
In the upcoming actions migration, we need fetch LNDs macaroons prior to initializing the stores, as the macaroons will be required during the migration. This requires that we setup the connection to LND before we initialize the stores, as we can only fetch the macaroons after the LND connection is established. In preparation of doing so, we cannot reference the stores when initializing/creating the sessions RPC server object, as we do so prior to setting up the LND connection. This commit therefore refactors the sessions RPC server so that we separate the initializing from the starting of the RPC server, and only require the store reference during the actual startup of the RPC server. Note that while this commit adds an `active atomic int32` to the RPC server which must be set toggled before the server will process requests, the RPC proxy and status manager will ensure that no requests get sent to the RPC prior to LiT's subserver being set to running. This is added to ensure that we dont introduce any nil pointer panics in future updates though, as the RPC server would panic in requests were actually processed prior to it having the dependencies injected during the `Start` function. Also note that we still keep the init of the sessions RPC server reference prior to setting up the LND connection, as not doing so would require that we'd refactor the registering of `GrpcSubserver`s in a more complex and in a less elegant way.
In the upcoming actions migration, we need fetch LNDs macaroons prior to initializing the stores, as the macaroons will be required during the migration. This requires that we setup the connection to LND before we initialize the stores, as we can only fetch the macaroons after the LND connection is established. This commit refactors the litd startup process, so that the stores are initialized after the LND connection is established.
In the upcoming actions migration, we will need to fetch LND's macaroons prior creating litd's stores, and therefore we need to connect to LND prior to creating the stores. To avoid having to wait for LND to fully sync before creating the stores (and, by extension, Litd's RPC servers), we separate the basic LND client setup from the full LND client setup. Only the full setup requires a fully synced LND.
ViktorTigerstrom
force-pushed
the
2025-08-actions-migration-prep
branch
from
0d9f96f to
8a4e962
Compare
|
The CI flake in the last push is not related to this PR, see: |
| // RPCServer is the main server that implements the Accounts gRPC service. | ||
| type RPCServer struct { | ||
| active int32 // atomic |
There was a problem hiding this comment.
I think atomic.Bool would be a better type here
| @@ -8,6 +8,7 @@ import ( | |||
| "fmt" | |||
| "strings" | |||
| "sync" | |||
| "sync/atomic" | |||
There was a problem hiding this comment.
nit: I think the commit message doesn't need to be repeated, it could just say that we do a similar separation like in the previous commit
| // sessionRpcServer is the gRPC server for the Session RPC interface. | ||
| type sessionRpcServer struct { | ||
| active int32 // atomic |
There was a problem hiding this comment.
same atomic.Bool as in the other commit
| g.accountRpcServer = accounts.NewRPCServer( | ||
| g.accountService, superMacBaker, | ||
| ) | ||
| g.accountRpcServer = accounts.NewRPCServer() |
There was a problem hiding this comment.
we make this change instead of also shifting it after the lnd connection creation in order to error out on RPC calls, right?
| return nil | ||
| } | ||
|
|
||
| // setupFullNDClient connects a up a full LND client to LND. Note that the setup |
This PR prepares litd's startup process in preparation for the actions migration.
In the upcoming actions migration, we need fetch LNDs macaroons prior to initializing the stores, as the macaroons will be required during the migration.
This requires that we setup the connection to LND before we initialize the stores, as we can only fetch the macaroons after the LND connection is established.
This PR refactors the litd startup process, so that the stores are initialized after the LND connection is established. This also requires that we refactor the RPC server setup, and separate the starting of the RPC servers from their creation, as litd's RPC servers prior to this PR require the stores to be initialized prior to being created.