In upcoming commits, we will introduce a new migration stream package
that will need to reference the db package, as well as the accounts,
session and firewalldb package in future commits. To avoid circular
dependencies, we therefore introduce a new migration stream that unit
tests can use, in order to avoid having to import the new migration
stream package.
As the legacy `NewTestPostgresDB` function is no longer used and has
been removed, it no longer makes sense to have a `V2` suffix on the
`NewTestPostgresV2DB` function. This commit renames it to
`NewTestPostgresDB`, to indicate that this function now replaces the
legacy function.
- Replace occurrences of `// nolint:lll` with `// nolint:ll` across
files for consistency.
- Reformat multiline strings, comments, and function parameters to
improve clarity and adhere to style guidelines.
- Add `// nolint:ll` comments where necessary to prevent linter
warnings.
In the bbolt store, an empty config for a feature is represented as an
empty array, while in for the SQL store, the same config is represented
as nil. Therefore, in the scenario where a specific feature has an empty
config, we override the SQL FeatureConfig for that feature to also be
set to an empty array. This is needed to ensure that the deep equals
check in the migration validation does not fail in this scenario.
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.
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.
This commit introduces the migration logic for transitioning the
sessions store from kvdb to SQL.
Note that as of this commit, the migration is not yet triggered by any
production code, i.e. only tests execute the migration logic.
We add a helper function to the functions that creates the test SQL
stores, in order to ensure that the store is properly closed when the
test is cleaned up.
In preparation for upcoming migration tests from a kvdb to an SQL store,
this commit updates the NewTestDB function to return the Store interface
rather than a concrete store implementation.
This change ensures that migration tests can call NewTestDB under any
build tag while receiving a consistent return type.
Add grpc interceptors that inject an LNC session's ID into the context
as gRPC metadata. By injecting it as such, it will be transported over
the wire in any outgoing gRPC calls.
This lets us be sure that any session call sent to the RPCMiddleware
interceptor in LND will continue to be grouped along with the
appropriate session ID. This gives LND a way to send the metadata we
include back to LiT meaning that we will later on be able to extract the
session ID again.
GetGroupID is given a session ID as a param and so should return
ErrSessionNotFound if that session is not found. GetSessionIDs is given
a groupID as a param and so should return ErrUnknownGroup if that group
does not exist.
This commit updates the kvstore and sql implementations to return the
correct error values and also ensures that this is properly tested now.
This commit updates:
- LND
- pool
- loop
- taproot-assets
- faraday
- lighting-node-connect
- aperture
- lndclient
- btclog
We start using the new btclog v2 library and the associated breaking
changes in the lnd/build package.
With this commit, we deprecate the `--remote.lit-maxlogfiles` and
`--remote.lit-maxlogfilesize` options and introduce new logging options
under the `--remote.lit-logging` namespace.
Finally, the LND update introduced a new `MaxBlocksMinedPerTest`
variable in the `lntest` package that we now need to override in order
for our itests to pass.
This commit adds the SQL implementation of the session.Store interface.
This can be run against all session unit tests via `make unit
pkg=session tags=test_db_sqlite` and `make unit pkg=session
tags=test_db_postgres`.
It's a better pattern to refer to sessions in the same way consistently.
So we update the UpdateSessionRemotePubKey method to use a session ID as
a reference to the session instead of local pub key.
In this commit, we more tightly & explicitly link a session to an
account. At a persitance layer, we have always only linked a session to
an account by encoding the AccountID within the macaroon caveat that we
store with the session. We still keep this persistence the same but now
we first ensure that the account exists and we also add an AccountID
field to the Session struct.
When we link a session to an account, we want to be able to validate
that the account actually does exist. So in preparation for that, we
first give the session store access to the accounts store.
Before we add the SQL implementation of the store, we fix this timestamp
to be a more realistic number. This is needed since in sqlite,
timestamps are serialised as strings and golang actually cant parse the
string for the current timestamp back into a time.Time. This is the
error that will be encountered:
`parsing time "99999-01-01 00:00:00 +0000 UTC" as "2006-01-02
15:04:05.999999999 -0700 MST": cannot parse "9-01-01 00:00:00 +0000 UTC"
as "-"`
We only really ever use it in one place and even then, only for a
session State that we no longer use anymore.
This is done to make the SQL queries we will need to implement the SQL
Store more simple.
In preparation for adding helpers with the same names but that will
compile under different build flags, we add the helper DB constructors
to use when testing the session store logic against a KVDB backend.
This was used to check that all linked sessions are no longer
active before attempting to register an autopilot session. But this is
no longer needed since this is done within NewSession.
In this commit, we let StateReserved be the new initial state of a
session for when NewSession is called. We then do predicate checks for
linked sessions along with unique session alias (ID) and priv key
derivations all under the same DB transaction in NewSession.
ShiftState then moves a session to StateCreated. Only in StateCreated
does a session become usable.
With this change, we no longer need to ensure atomic session creation by
acquiring the `sessRegMu` mutex in the session RPC server.
