During testing of this PR I figured out the the htlc interceptor
was not shutdown and started properly in terms of closing the
quit channel but also in terms of the relevant logs.
This commit updates the invoice registry to utilize the settlement
interceptor during the invoice settlement routine. It allows the
interceptor to capture the invoice, providing interception clients an
opportunity to determine the settlement outcome.
This commit introduces a new invoice htlc interceptor service
that intercepts invoice HTLCs during their settlement phase. It forwards
HTLCs to a subscribed client to determine their settlement outcomes.
This commit also introduces an interface to facilitate integrating the
interceptor with other packages.
Introduce `ResumeModified` action to resume standard behavior of a p2p
message with optional modifications as specified by the client during
interception.
Previously, the SQL implementation of the invoice query simply
converted the start and end timestamps to time and used them
in SQL queries to check for inclusivity. However, this logic
failed when the start and end timestamps were equal.
This commit addresses and corrects this issue.
Previously SQL invoice updater ignored the set ID hint when updating an
AMP invoice resulting in update subscriptions returning all of the AMP
state as well as all AMP HTLCs. This commit synchornizes behavior with
the KV implementation such that we now only return relevant AMP state
and HTLCs when updating an AMP invoice.
The BlindedPathConfig struct is nice for invoice creation but when we
use the Invoice message for viewing an invoice, it would be nicer to see
an "is_blinded" field.
With this PR we might call the stop method even when the start
method of a subsystem did not successfully finish therefore we
need to make sure we guard the stop methods for potential panics
if some variables are not initialized in the contructors of the
subsystems.
We've covered all the logic for building a blinded path to ourselves and
putting that into an invoice - so now we start preparing to actually be
able to recognise the incoming payment as one from a blinded path we
created.
The incoming update_add_htlc will have an `encrypted_recipient_data`
blob for us that we would have put in the original invoice. From this we
extract the PathID which we wrote. We consider this the payment address
and we use this to derive the associated invoice location.
Blinded path payments will not include MPP records, so the payment
address and total payment amount must be gleaned from the pathID and new
totalAmtMsat onion field respectively.
This commit only covers the final hop payload of a hop in a blinded
path. Dummy hops will be handled in the following commit.
Previously, when using the native schema, invoice expiries were incorrectly
stored as 64-bit values (expiry in nanoseconds instead of seconds), causing
overflow issues. Since we cannot determine the original values, we will set
the expiries for existing invoices to 1 hour with this migration.
Previously paginated queries offseted the add_index_get, add_index_let,
settle_index_get and settle_index_let parameters with the paginators
current page offset, however this was incorrect as we can just use
SQL's LIMIT/OFFSET to paginate. This commit fixes this issue and adds an
optional parameter to the constructor of the invoice SQL store to set
page size. This is useful when testing as we can now cover pagination
correctly with our existing unit tests.
Add a temporary mutex around the calls to sqldb.NewTestSqliteDB to
ensure that only a single thread can access it at a time. This is a
temporary work around that can be removed once this race condition in
the sqlite repo has been resolved:
https://gitlab.com/cznic/sqlite/-/issues/180
Previously if the `reverse` named arg was unset (value of NULL), then
SQL would order by NULL instead of ID causing undifined ordering of the
returned rows. To fix that we check for NULL and also make sure to set
the `reverse` arg in the code explicitly as it in the generated code it
is an `interface{}` instead of `bool`.
For SQL transactions, we often accumulate results in variables declared
outside the closure's scope. To eliminate the need for manually clearing
these containers, we introduce a reset function to ExecTx, mirroring the
approach already adopted in kvdb.
This commit extracts the InvoiceDB construction from all invoice and
registry tests such that we can later on run subtests with multiple
backends without needing to use tags.
With the introducation of the `InvoiceUpdater` interface we are now
able to move the non-kv parts of `UpdateInvoice` completely under
the invoices package. This is a preprequisite for being able to use
the same code-base for the sql InvoiceDB implementation of
UpdateInvoice.
This commit introduces the InvoiceUpdater interface which is meant
to abstract and assist the in-memory invoice update procedure with
the accompanying database updates. These abstract updater steps will
enable further refactoring later while also ensuring that a full
SQL implementation of the InvoiceDB interface will be possible.
In this commit we change how we select invoices to follow or delete when
starting the InvoiceRegistry to instead of using the deperecated scan
func from channeldb, use specific functions to gather pending and delete
canceled invoices.
* multi: extend InvoiceDB methods with a context argument
This commit adds a context to InvoiceDB's methods. Along this refactor
we also extend InvoiceRegistry methods with contexts where it makes
sense. This change is essential to be able to provide kvdb and sqldb
implementations for InvoiceDB.
* channeldb: restrict invoice tests to only use an InvoiceDB instance
* docs: update release notes for 0.18.0
