Previously, we would only check the workspace as a whole. This however
would mean that we would check/test crates with `lightning`'s default
features enabled, allowing failures-to-build under the crates own
default features to slip through, if they didn't explicitly enable
`lightning/std`, for example.
Here, we extend the CI to check the workspace as a whole but then run
checks, tests, and doc generation on the workspace members individually,
asserting that all of them build even when not built as part of the same
workspace as `lightning`.
429cbe1a06 merged a PR that renamed
Offer::signing_pubkey to Offer::issuer_signing_pubkey. However, there was a
silent rebase conflict and a test added as part of
1059f5ffc5 did not get the memo and used the old
method name, breaking the test build.
This fixes the following bug:
- An outbound payment is AwaitingInvoice
- We receive an invoice and lock the HTLCs into the relevant ChannelMonitors
- The monitors are successfully persisted, but the ChannelManager fails to
persist, so the outbound payment remains AwaitingInvoice
- We restart, causing the channels to close due to a stale ChannelManager
- We receive a duplicate invoice, and attempt to pay it again due to the
payment still being AwaitingInvoice in the stale ChannelManager
After the fix for this, we will notice that the payment is already locked into
the monitor on startup and transition the incorrectly-AwaitingInvoice payment
to Retryable, which prevents double-paying on duplicate invoice receipt.
The spec was recently changed to use offer_issuer_id instead of
offer_node_id. LDK always used signing_pubkey to avoid confusion with a
node_id. Rename it to issuer_signing_pubkey now as InvoiceRequest and
Bolt12Invoice will have similarly named methods in upcoming commits.
Move the code that ensures that HTLCs locked into ChannelMonitors are
synchronized with the ChannelManager's OutboundPayments store to the
outbound_payments module.
This is useful both because ChannelManager::read is very long/confusing method,
so it's nice to encapsulate some of its functionality, and because we need to
fix an existing bug in this logic where we may risk double-paying an offer due
to outbound_payments being stale on startup. See the next commit for this
bugfix.
Currently we don't have any visibility if BackgroundProcessor
takes considerably more of time to process events, adding logs
to help debug such issues.
While these variants may sound similar, they are very different. One is so
temporary it's never even persisted to disk, the other is a state we will stay
in for hours or days. See added docs for more info.
Currently used when initiating an async payment via held_htlc_available OM. This
OM needs a reply path back to us, so use this error for our invoice_error OM if
we fail to create said reply path.
See AsyncPaymentsContext::hmac, but this prevents the recipient from
deanonymizing us. Without this, if they are able to guess the correct payment
id, then they could create a blinded path to us and confirm our identity.
We also move the PAYMENT_HASH_HMAC_INPUT const to use &[7; 16], which is safe
because this const was added since the last release. This ordering reads more
smoothly.
We want to specify that these methods are only to be used in an outbound offers
payment context, because we'll be adding similar methods for the outbound async
payments context in upcoming commits.
