When using MPP, if we can't find a route, we need to add an entry to the
DB. Otherwise when users query their payment status, nothing will be
returned which is a bad UX.
Fixes#1512
We were previously using an encoding that was incompatible with TLV.
We keep the old format, but also understand the channel version when provided
in a TLV field.
If the old format is provided, it will be preferred.
Instead of waiting for latest feerates from the fee provider at startup,
we use the previously stored feerates in the meantime, and proceed with
the initialization.
It makes sense because fees are asynchronous so we are "always late"
anyway.
manualTransition is a fix for old akka version where onTransition events
are not fired for same state transitions. Must not be used if states are
different, otherwise duplicate events are fired.
Shuffle methods around between ExtendedBitcoinClient and
BitcoinCoreWallet to help readability and separate concerns.
Add some documentation and fix harmless warnings.
Add bitcoin client tests.
* Non blocking bounded mailbox for backup handler
Akka 2.4 introduced a non-blocking unbounded mailbox.
It makes sense to upgrade the backup handler to that mailbox type.
We also add some backup-related metrics.
* Wrap DB calls to record metrics
We record the number of times each operation is executed and its
duration.
When we receive an `UpdateFulfillHtlc` from a downstream channel, it is
critical that we don't lose it because that is what allows us to pull
funds from the corresponding upstream channel(s). But this(ese) upstream
channel(s) may very well be currently OFFLINE and unable to update the
commitment right away, so we need to remember it for later. Same applies
to an `UpdateFailHtlc` (although it is less critical), because we don't
want the upstream htlc to timeout and cause a channel to force-close.
We were previously relying on a `CommandBuffer` actor, that uses a
"pending relay" database to store commands. Once the command is processed
by the target channel, it sends back an acknowledgment to the
`CommandBuffer`, which then removes the command from the database.
Unacknowledged commands are replayed at each reconnection or app restart.
This works well, but the flow is a little cumbersome and not easy to
understand.
With this PR, the sender (channel, payment handler, ...) is responsible for
storing commands to the pending relay db, instead of the command buffer,
which is completely removed. The target channel will acknowledge the
message and remove it from the pending relay db.
In the end, the logic is the same as before, we have just dropped the
intermediate `CommandBuffer`.
* Split feerate mismatch configuration
We want to be much stricter with feerates that are below our estimation
than feerates that are above it.
This also makes this configuration parameter easier to understand
for end users.
* Tolerate feerate mismatch while channel is unused
We can relax the conditions where we close a channel because of a feerate
mismatch: when the channel has no pending HTLCs, it's ok to temporarily
disagree on the feerate.
While we disagree on feerates, we don't use this channel to offer outgoing
HTLCs. If we receive an incoming HTLC, we have to close the channel because
that HTLC would be at risk (incorrect feerate).
This mechanism gives us time to adapt to feerate changes, hopefully reducing
the amount of unnecessary channel closures.
The channelstats API only returns results for the *outgoing* channels
used when relaying. We must also include the *incoming* channels, otherwise
it looks like they're inactive which doesn't reflect their real usage.
Fixes#1465
- Test was not executed (because the "tests" variable was an iterator that was emptied by the call to .size())
- HTLC regex had to be updated to skip over the HTLC number that was added to the reference test vectors
* Add metric to track onion payload format
This will be useful to decide when we can safely phase out support for
the legacy format.
* Add metric to track htlcs in flight
We track both the number of HTLCs and their amounts.
We track this at the channel level and globally.
If all trampoline retries fail, we should convert the error to a route
not found. We tried multiple fee targets and none of those was enough to
allow the trampoline node to find a satisfying route.
