Commit Graph

45 Commits

Author SHA1 Message Date
Joost Jager
cc37485432
routing: return full htlc attempt from shard handler 2020-05-12 19:56:50 +02:00
Joost Jager
5d0a117162
routing: fix log 2020-04-08 08:14:10 +02:00
Johan T. Halseth
5e72a4b77c
routing: exit on unexpected RequestRoute error
We whitelist a set of "expected" errors that can be returned from
RequestRoute, by converting them into a new type noRouteError. For any
other error returned by RequestRoute, we'll now exit immediately.
2020-04-02 19:31:24 +02:00
Johan T. Halseth
7b318a4be7
routing/payment_lifecycle+channeldb: enable multi shard send
This commit finally enables MP payments within the payment lifecycle
(used for SendPayment). This is done by letting the loop launch shards
as long as there is value remaining to send, inspecting the outcomes for
the sent shards when the full payment amount has been filled.

The method channeldb.MPPayment.SentAmt() is added to easily look up how
much value we have sent for the payment.
2020-04-02 19:29:15 +02:00
Johan T. Halseth
5adfc968df
routing/payment_lifecycle: return recorded errors
In preparation for MPP we return the terminal errors recorded with the
control tower. The reason is that we cannot return immediately when a
shard fails for MPP, since there might be more shards in flight that we
must wait for. For that reason we instead mark the payment failed in the
control tower, then return this error when we inspect the payment,
seeing it has been failed and there are no shards in flight.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
7b5c10814b
routing/payment_lifecycle+channeldb: collect existing outcome first
To move towards how we will handle existing attempt in case of MPP
(collecting their outcome will be done in separate goroutines separate
from the payment loop), we move to collect their outcome first.

To easily fetch HTLCs that are still not resolved, we add the utility
method InFlightHTLCs to channeldb.MPPayment.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
49efbefb43
routing/payment_session: remove prebuilt payment session
Since we no longer use payment sessions for send to route, we remove the
prebuilt one.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
4509c4f3a9
routing: move ErrMaxRouteHopsExceeded check
Now that SendToRoute is no longer using the payment lifecycle, we move
the max hop check out of the payment shard's launch() method, and return
the error directly, such that it can be handled in SendToRoute.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
a979b91b27
routing: remove errNoRoute and lastError
Now that SendToRoute is no longer using the payment lifecycle, we
remove the error structs and vars used to cache the last encountered
error. For SendToRoute this will now be returned directly after a shard
has failed.

For SendPayment this means that the last error encountered durinng
pathfinding no longer will be returned. All errors encounterd can
instead be inspected from the HTLC list.
2020-04-02 10:24:35 +02:00
Johan T. Halseth
2c01e79eb5
routing/payment_lifecycle: extract result collection into collectResult
Fetching the final shard result will also be done for calls to
SendToRoute, so we extract this code into a new method.

We move the call to the ControlTower to set the payment level failure
out into the payment loop, as this must be handled differently when
multiple shards are in flight, and for SendToRoute.
2020-04-02 10:24:34 +02:00
Johan T. Halseth
9712dd1a7f
routing/payment_lifecycle: extract attempt sending logic
Define shardHandler which is a struct holding what is needed to send
attempts along given routes. The reason we define the logic on this
struct instead of the paymentLifecycle is that we later will make
SendToRoute calls not go through the payment lifecycle, but only using
this struct.

The launch shard is responsible for registering the attempt with the
control tower, failing it if the launch fails. Note that it is NOT
responsible for marking the _payment_ failed in case a terminal error is
encountered. This is important since we will later reuse this method for
SendToRoute, where whether to fail the payment cannot be decided on the
shard level.
2020-04-02 10:24:34 +02:00
Johan T. Halseth
bcca1ab821
routing/payment_lifeycle: remove payment level attempt and circuit
We replace the cached attempt, and instead use the control tower
(database) to fetch any in-flight attempt. This is done as a
preparation for having multiple attempts in flight.

In addition we remove the cached circuit, as it won't be applicable when
multiple shards are in flight.

Instead of tracking the attemp we consult the database on every
iteration, and pick up any existing attempt. This also let us avoid
having to pass in the existing attempts from the payment loop, as we
just fetch them direclty.
2020-04-02 10:24:34 +02:00
Johan T. Halseth
4485e8261f
routing/payment_lifecycle: move Fail call to payment loop
In our quest to move calls to the ControlTower into the main payment
lifecycle loop, we move the edge case of a too long route out of
createNewPaymentAttempt.
2020-04-02 10:24:33 +02:00
Johan T. Halseth
3620721391
routing/payment_lifecycle: move attempt DB checkpointing into payment
loop

To prepare for multiple in flight payment attempts, we move
checkpointing the payment attempt out of createNewPaymentAttempt and
into the main payment lifecycle loop.

We'll attempt to move all calls to the DB via the ControlTower into this
loop, so we can more easily handle them in sequence.
2020-04-02 10:24:33 +02:00
Johan T. Halseth
e61fcda6a9
routing/payment_lifecycle: move requesting route out of createNewPaymentAttempt
To prepare for having more than one payment attempt in flight at the
same time, we decouple fetching the next route from crafting the payment
attempt.
2020-04-02 10:24:33 +02:00
Johan T. Halseth
00903ef9f5
routing/payment_session: make RequestRoute take max amt, fee limit and
active shards

In preparation for doing pathfinding for routes sending a value less
than the total payment amount, we let the payment session take the max
amount to send and the fee limit as arguments to RequestRoute.
2020-04-02 10:24:33 +02:00
Johan T. Halseth
f9eeb6b41f
routing/router+lifecycle: remove LightningPayment from payment lifecycle
Now that the information needed is stored by the paymentSession, we no
longer need to pass the LightningPayment into the payment lifecycle.
2020-04-02 10:24:33 +02:00
Johan T. Halseth
c2301c14b2
routing/payment_session: make NewPaymentSession take payment directly
This commit moves supplying of the information in the LightningPayment
to the initialization of the paymentSession, away from every call to
RequestRoute.

Instead the paymentSession will store this information internally, as it
doesn't change between payment attempts.

This is done to rid the RequestRoute call of the LightingPayment
argument, as for SendToRoute calls, it is not needed to supply the next
route.
2020-04-02 10:24:33 +02:00
Joost Jager
f86e68a1a2
channeldb+routing: store full htlc failure reason
This commit extends the htlc fail info with the full failure reason that
was received over the wire. In a later commit, this info will also be
exposed on the rpc interface. Furthermore it serves as a building block
to make SendToRoute reliable across restarts.
2020-03-09 18:31:35 +01:00
Joost Jager
48c0e42c26
channeldb+routing: store all payment htlcs
This commit converts the database structure of a payment so that it can
not just store the last htlc attempt, but all attempts that have been
made. This is a preparation for mpp sending.

In addition to that, we now also persist the fail time of an htlc. In a
later commit, the full failure reason will be added as well.

A key change is made to the control tower interface. Previously the
control tower wasn't aware of individual htlc outcomes. The payment
remained in-flight with the latest attempt recorded, but an outcome was
only set when the payment finished. With this commit, the outcome of
every htlc is expected by the control tower and recorded in the
database.

Co-authored-by: Johan T. Halseth <johanth@gmail.com>
2020-03-09 18:31:33 +01:00
Johan T. Halseth
bee2380441
channeldb: rename PaymentAttemptInfo to HTLCAttemptInfo
To better distinguish payments from HTLCs, we rename the attempt info
struct to HTLCAttemptInfo. We also embed it into the HTLCAttempt struct,
to avoid having to duplicate this information.

The paymentID term is renamed to attemptID.
2020-03-09 11:43:26 +01:00
Joost Jager
b760b25229
routing: limit routing info size during pathfinding
Also the max hop count check can be removed, because the real bound is
the payload size. By moving the check inside the search loop, we now
also backtrack when we hit the limit.
2019-12-20 11:00:05 +01:00
Conner Fromknecht
990d55d08c
routing/pathfind: ensure final hop supports payment addrs
This commit adds an optional PaymentAddr field to the RestrictParams, so
that we can verify the final hop can support it before doing an
expensive round of pathfindig.
2019-12-18 23:54:31 -08:00
Joost Jager
31b2c22cf5
routing: check for invalid routes 2019-12-16 14:53:45 +01:00
Joost Jager
b8abae6a7e
routing: rename route variable to prevent clash with package 2019-12-14 08:47:53 +01:00
Joost Jager
97344af8f3
routing: local balance check 2019-12-04 09:45:07 +01:00
Joost Jager
c15b0316a2
routing: use FailureReasonError for internal path finding errors 2019-11-27 15:21:12 +01:00
Joost Jager
a364d2cd82
routing: log route when payment attempt fails 2019-11-12 14:13:31 +01:00
Joost Jager
ff0c5a0d5e
routing: process successes in mission control
This commit modifies paymentLifecycle so that it not only feeds
failures into mission control, but successes as well.
This allows for more accurate probability estimates. Previously,
the success probability for a successful pair and a pair with
no history was equal. There was no force that pushed towards
previously successful routes.
2019-08-23 09:15:41 +02:00
Joost Jager
e7af6a077a
routing: convert to nillable failure reason
This commit converts several functions from returning a bool and a
failure reason to a nillable failure reason as return parameter. This
will take away confusion about the interpretation of the two separate
values.
2019-08-17 10:23:57 +02:00
Joost Jager
b4a7665bae
routing: provide payment id to mission control 2019-07-29 09:38:32 +02:00
Joost Jager
8055bcf2e0
routing: report failures to mission control directly
As there is no more state kept in the payment session, failure reporting
can go straight to mission control.
2019-07-13 22:38:25 +02:00
Joost Jager
418fe364de
htlcswitch: use distinct error for unreadable failures 2019-07-11 19:49:45 +02:00
Olaoluwa Osuntokun
ba5fbb3c27
Merge pull request #3156 from joostjager/extended-fail
routerrpc: add more failure reasons and route hints
2019-07-08 19:12:03 -07:00
Joost Jager
ae46fb00cb
routing+channeldb: add more failure reasons 2019-07-04 09:27:12 +02:00
Johan T. Halseth
8b83f03308
rpcserver+router: log terminal sendPayment error 2019-07-01 16:22:57 -07:00
Joost Jager
2e920de292
routing+lnrpc: move default payment timeout out of router
This commit moves the default timeout out of router and thereby fixes a
bug that caused SendToRoute to not return the actual error, but a
timeout result instead. SendToRoute only tries a single route, so a
timeout should never happen.
2019-06-11 08:36:17 +02:00
Johan T. Halseth
2dea790b55
multi: make GetPaymentResult take payment hash
Used for logging in the switch, and when we remove the pending payments,
only the router will have the hash stored across restarts.
2019-06-07 16:53:32 +02:00
Joost Jager
0e273a5731
routing: return structured error for send to route 2019-05-29 14:06:58 +02:00
Johan T. Halseth
1b788904f0
channeldb+router: record payment failure reason in db 2019-05-27 20:18:59 +02:00
Johan T. Halseth
f4306b1178
routing/payment_session+router: make PaymentSession interface 2019-05-27 20:18:58 +02:00
Johan T. Halseth
de1bf8a518
routing/router: persist payment state machine
This commit makes the router use the ControlTower to drive the payment
life cycle state machine, to keep track of active payments across
restarts.  This lets the router resume payments on startup, such that
their final results can be handled and stored when ready.
2019-05-27 20:18:58 +02:00
Johan T. Halseth
dd73c51a34
routing/payment_lifecycle: extract create attempt into method 2019-05-27 20:18:58 +02:00
Johan T. Halseth
e9b2182cdc
routing/payment_lifecycle: extract error handling into method 2019-05-27 20:18:58 +02:00
Johan T. Halseth
83bfaa4fb4
routing: extract payment flow into method on paymentLifecycle
This encapsulates all state needed to resume a payment from any point of
the payment flow, and that must be shared between the different stages
of the execution. This is done to prepare for breaking the send loop
into smaller parts, and being able to resume the payment from any point
from persistent state.
2019-05-27 20:18:57 +02:00