Store explicit positions for session macaroon caveats and permissions
in the SQL schema and read them back in position order. Also remove the
migration-time sorting workaround in session comparison, so migration
validation now checks the actual persisted order instead of masking it.
This is needed because session caveat order is not just presentation
data. LiT adds caveats to the baked macaroon in slice order, and the
macaroon library updates the signature hash chain for each added caveat.
Reordering caveats can therefore change the resulting macaroon bytes and
signature.
The previous schema split caveats and permissions into child tables
without any position column, and the SQL reads had no ORDER BY. The KV
store preserves slice order, but SQL had no explicit way to reproduce
that order after migration or on later reads. The migration code’s old
sorting step was only making validation deterministic; it did not
preserve the original recipe order.
Permissions are canonicalized by lnd when baking, so their order is less
semantically important for the final macaroon. They still get positions
here so the stored recipe remains faithful to the original session data
and both child tables behave consistently.
Why it was needed:
- caveats needed explicit order preservation because they are appended
and signed in order.
- The old SQL schema did not store order, and the read queries did not
request one.
- Adding position makes the SQL representation faithful to the KV/TLV
recipe instead of relying on incidental row order.
- Adding it to permissions too keeps the stored recipe lossless and
consistent, even though lnd. canonicalizes permissions before baking.
NOTE: This commit explicitly edits the previous migration instead of
adding a new one. This is ok as SQL dbs are not yet supported in
production, so there are no live deployments to worry about.
Migrate KV firewall actions by traversing the global actions-index
instead of iterating per-session buckets, so SQL action IDs follow the
same global creation order as the legacy KV store.
Also stabilize SQL action listing by ordering on created_at and id,
using id as a deterministic tie-breaker when multiple actions share the
same timestamp.
This is needed because KV actions have a real global sequence in
actions-index, while the old migration assigned SQL IDs based on bucket
traversal order. That could reorder legacy actions during migration.
Separately, ordering by created_at alone was not stable for equal
timestamps, so action queries could return different orders for the
same data.
NOTE: This commit explicitly edits the previous migration instead of
adding a new one. This is ok as SQL dbs are not yet supported in
production, so there are no live deployments to worry about.
Remove the KVDB-to-SQL migration from the dev SQL migration set now
that this migration is now part of the production migration set.
As the migrations_dev folder no longer contains any migrations, we also
update the db logic and the gen_sqlc_docker.sh script to not error when
the folder(s) are empty.
Move the programmatic KVDB-to-SQL migration out of the dev-only
migration stream and into the production SQL migration set.
This also requires that we add a new migration file for the prod
migration, which will trigger the kvdb to sql programmatic migration to
run in production.
Replace the single kvstores UNIQUE index with namespace-specific partial
unique indexes and add a check that feature-scoped records always have
a group_id.
This is needed because the old uniqueness constraint covered nullable
columns. In SQL, NULL values do not compare equal inside a UNIQUE index,
so duplicate global and group-scoped kvstore rows could be inserted even
though the legacy KVDB bucket layout only allows one record per logical
namespace.
The new indexes mirror the KVDB model directly:
global rows are unique by entry_key, rule_id, and perm; group rows add
group_id; feature rows add feature_id. The CHECK constraint also blocks
invalid feature rows that are not attached to a group.
NOTE: This commit explicitly edits the previous migration instead of
adding a new one. This is ok as SQL dbs are not yet supported in
production, so there are no live deployments to worry about.
This commits ensures that the `CountActions` function in the `sqlc` &
`sqlcmig6` packages utilizes the `fillPlaceHolders` function to properly
handle SQL query placeholders.
This ensures that the function works correctly on `Postgres` backends
when it contains ? placeholders instead of positional ones (e.g., $1).
Optimize SQL account listing by preloading linked invoices and payments
for all accounts in bulk.
Before this change, Accounts() queried ListAllAccounts and then did two
extra queries per account (ListAccountInvoices/ListAccountPayments),
which scales poorly as account count grows.
Add ListAllAccountInvoices and ListAllAccountPayments queries, group
their rows by account_id in memory, and marshal each account from the
preloaded data. Keep conversion logic shared through
marshalDBAccountWithLinkedData to preserve behavior between
single-account and list-account paths.
This reduces query count from 1 + 2N to 3 and improves list-path
performance without changing external semantics.
When the kvdb to sql migration is initially introduced, we will want to
ensure that it is only run under dev builds during the testing phase.
We therefore introduce the functionality to have separate dev
migrations, which are only included in a separate migration stream that
is used only in dev builds.
Note that these dev migrations are currently not included in the
`sqlc.yaml` file, to ensure that the main sqlc models doesn't include
the dev migrations.
As no code path uses the sqlc.UpdateAccountAliasForTests query, now that
migrations tests have been updated to use the sqlcmig6 version, we can
remove the query from the sqlc package. As this query is only intended
to be used for testing, it is beneficial to not expose it to the rest of
the codebase to avoid accidental usage in the future.
As we've now switched over to using sqldb v2 for most of the db objects,
we can remove a lot of deprecated code that's no longer used in the litd
project. This commit removes that code.
The upcoming implementation of `sqldb/v2` will extensively create
a `Queries` object on the fly. To make more intuitive how to create
the queries object for specific database types, we introduce a
`NewForType` helper method.
This also mimics how `tapd` creates the `Queries` object, and in order
not let `litd` have it's own definition of how `Queries` object are
created on the fly, the upcoming `sqldb/v2` usage will utilize this
helper method.
The `sqldb/v2` package now provides a definition for the `BackendType`
type. As useage of `sqldb/v2` requires useage of that type, we update
`litd` to use the `BackendType` definition from `sqldb/v2`, instead of
it's own definition.
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.
Rename the session_id to group_id in kvstores table in the SQL store, to
better represent how the field is actually used.
Note that this is a breaking change, and would normally require a new
migration. But as the SQL store is not used in production, and only
enabled under the dev build flag, we can rename it without a new
migration, as there's no users of the SQL store in production.
During the upcoming upcoming migration of the firewall database to SQL,
we need to be able to check all kvstores records in the SQL database,
to validate that the migration is successful in tests.
This commits adds a query to list all kvstores records, which enables
that functionality.
Here, we manually define some queries for the actions store. We do this
so that we can manually build the "SELECT" and only add "WHERE" clauses
that are actually needed for the query and hence ensure that available
indexes are used.
In this commit we define the schema for the `actions` table along with
various queries we will need for interacting with the table. NOTE: we
will also add some of our own queries manually in commits to follow.
In preparation for the migration from kvdb to SQL, we update the results
of the ListAllAccounts query. After the migration has been implemented,
we will test that the result off all accounts in the SQL database
is the same as the result of the fetching all accounts in the kvdb.
By ordering the SQL query's result by account id, we ensure that all
accounts are returned in the same order as they are returned by the
kvdb.
Replace any named UNIQUE indices in the accounts tables and replace with
named ones. This is for a future where we want to be able to edit these
indices without having to drop the table.
It is fine for us to just edit these tables since these are not
available in "prod" yet.
This commit adds the boilerplate code we will need in order to start
using SQL backed stores (namely sqlite and postgres) for our DB backend.
NOTE that this has been copied from the taproot-assets repo.
This commit also contains the sqlc.yaml file, the `make sqlc` command
and the script for generating sqlc code. This must be done in this
commit as the script only works if there are queries to generate from.
