In the upcoming kvdb to SQL migration of the actions store, we need to
simulate in tests that two or more accounts have colliding account
aliases for the first 4 bytes of the alias. In order to allow creation
of such accounts, we need to be able to update the alias of an account
in tests, and this commit adds the a SQL query enabling this
functionality.
Note that the `UpdateAccountAliasForTests` query is only intended for
use in tests and should not be used in production code.
Add helper method to `AddActionReq` returns the 4 byte macaroon ID that
is derived from the MacaroonRootKeyID. Using the helper removes some
code repetition at call sites, and makes the intended usage clearer.
As the `MacaroonRootKeyID` field of the `AddActionReq` struct also
contains the 4 bytes of the `MacaroonIdentifier`, we change all
call sites to instead use the last 4 bytes of the `MacaroonRootKeyID`
field. As the `MacaroonIdentifier` field therefore becomes redundant,
we also remove it.
When migrating the actions store from kvdb to sql, we will update the
existing actions to include the full mac root key, instead of just the
last 4 bytes (currently called `MacaroonIdentifier`). In order to do so,
we change the sql implementation of the `actions` store to persist the
full mac root key, instead of just the last 4 bytes. As no production
data in the sql actions store exists for users yet, it's fine for us to
change this without having to address old sql actions which only stored
the last 4 bytes.
Note though that since old actions stored in the kvdb implementation
only have the last 4 bytes of the mac root key persisted, we will only
ever persist the last 4 byte of the mac root key ID for kvdb actions.
When the actions are later read back from the kvdb store, the first 4
bytes of the mac root key ID will be padded with zeroes to make up the
full 8 bytes.
As no call site currently utilizes the full 8 bytes of the mac root key
ID, this is okay for now. When we later deprecate and remove the kvdb
implementation, we can then update the rest of `litd` to also use the
full mac root key ID.
The upcoming commit will update the `AddActionReq` struct to include an
extra field which the `kvdb` actions store will ignore. Therefore the
`assertEqualActions` for the `kvdb` version will need to be update to
ignore this field. In preparation for that change, we also do another
optimization of the `assertEqualActions` function under kvdb builds, to
not mutate the passed action references.
If a user creates a session linked to an account, but later deletes that
account using the `litcli accounts remove` command, the KVDB session
will still contain the account ID of the removed account.
During the KVDB to SQL migration, the accounts migration runs before the
sessions migration. Since the deleted account no longer exists, it
cannot be migrated. As a result, the migrated SQL session cannot link to
the now non-existent account in the SQL store.
In such cases, we will migrate the session and not link to any account
in the SQL session.
In preparation for the next commit which bumps golang to a newer
version, we want to make some code changes that would otherwise render
some log-related calls problematic. With go1.24 a new govet rule was
added that disallows non-constant strings (i.e including a tag like
"%s") in calls to printf. See more in the related issue
https://github.com/golang/go/issues/60529.
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.
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.
Similar to how the previous commit separated the initialization and
starting of the account RPC server, this commit separates the
initialization and starting of the sessions RPC server.
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 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.
As it's quite confusing by just looking at `litd` codebase that LND will
execute `litd`'s `RegisterGrpcSubserver` function during the setup of
the LND connection, we add a comment to clarify this.
The logic to avoid duplicate session IDs was first added with the
session linking linking functionality. That means that there may be old
legacy sessions that were added prior to that which may have duplicate
IDs. Before this commit, such sessions would cause the kvdb to SQL
migration to error, as there is a uniqueness constraint on the legacy
session alias in the SQL sessions table.
We want to keep that constraint, so in such rare cases, we update the
kvdb to SQL migration logic to drop all but the session with the
latest CreatedAt time if for sessions that share the same ID.
That follows the logic in c8b78bd10d as
closely as possible, as that migration ensured that all sessions but the
latest one was revoked if multiple sessions shared the same ID.
In the upcoming commit, we will update the kvdb to sql migration to not
always include all sessions in the kvdb store. Therefore, we update the
kvdb to migration tests in order to be able to handle such cases by
including the expected results for each test case.
Similar to the previous commit, we also sort the
`MacaroonRecipe.Permissions` slice to ensure it can be compared in a
deterministic manner during migrations.
In the kvdb to sql migration, if there have been caveats set for the
MacaroonRecipe, the order of the postgres db caveats will in very rare
cases differ from the kv store caveats. Therefore, we sort both the kv
and sql caveats by their ID, so that we can compare them in a
deterministic way.
