You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This creates a new phase for SwapDeals called `PreimageResolved` that
represents the part after the maker has completed its payment to taker
and resolved the preimage, but before it has settled its incoming
payment using the preimage.
Swaps that have reached this phase are considered atomic - our outgoing
payment has been settle and we've acquired the ability to settle our
incoming payment - even if they're not complete. Therefore, the maker
ends the swap timeout and gives the call to settle the incoming payment
as long as it needs to complete while keeping the hold on the order to
prevent it from being filled a second time.
Should a swap fail the `settleInvoice` call, it enters swap SwapRecovery
where settling the payment will be attempted one more time but only
after ensuring we are connected to the SwapClient responsible for that
payment. Previously, deals that hit an error upon the `settleInvoice`
would not fail the deal and send it to recovery until the timeout was
reached.
We persist the preimage to the database immediately upon reaching the
`PreimageResolved` phase and then use that preimage in SwapRecovery if
it is available, rather than querying the swap client for the outgoing
payment to lookup the preimage again.
We modify the timeout behavior for the maker in the swap. The maker will
no longer "fail" a deal once it has begun sending its payment to the
taker due to a swap timing out. Instead it will only notify the taker
that its time limit has been reached, and a cooperative taker will
cancel its invoice and call off the swap.
The maker also tracks the elapsed time for a swap, and if its payment to
taker succeeds after the time out period it penalizes the taker for
accepting payment and settling its invoice too late. Takers that delay
before they settle payment can abuse the free options problem.
On the swap recovery side, we no longer fail a recovered deal if a
settle invoice call fails. Instead, we continuosly attempt settle
invoice calls until one succeeds. Longer term we can permanently stop
settle invoice attempts if we can recognize the sorts of errors that
indicate permanent failure such as htlc expiration or an unrecognized
invoice hash.
Resolves#1654. Resolves#1659.
this.logger.info(`recovered ${deal.makerCurrency} swap payment of ${deal.makerAmount} using preimage ${deal.rPreimage}`);
100
-
}
101
-
102
-
this.pendingSwaps.delete(deal.rHash);
103
-
awaitdeal.save();
104
-
// TODO: update order and trade in database to indicate they were executed
105
-
}catch(err){
106
-
// tslint:disable-next-line: max-line-length
107
-
this.logger.error(`could not settle ${deal.makerCurrency} invoice for payment ${deal.rHash} and preimage ${deal.rPreimage}, **this must be resolved manually**`,err);
108
-
awaitthis.failDeal(deal);
109
-
}
123
+
deal.rPreimage=paymentStatus.preimage!;
124
+
awaitdeal.save();// persist the preimage to the database once we retrieve it
0 commit comments