Swap not monitored after connext failed sendpayment and xud restarted #1799
Comments
|
This one is definitely still open, opened another issue: #1818 |
sangaman
added a commit
that referenced
this issue
Aug 18, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1816. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1816.
sangaman
added a commit
that referenced
this issue
Aug 19, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1816. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1816.
sangaman
added a commit
that referenced
this issue
Aug 19, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1816. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1816.
sangaman
added a commit
that referenced
this issue
Aug 19, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1816. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1816.
sangaman
added a commit
that referenced
this issue
Aug 19, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1816. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1816.
sangaman
added a commit
that referenced
this issue
Aug 21, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1794.
sangaman
added a commit
that referenced
this issue
Aug 25, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1794.
sangaman
added a commit
that referenced
this issue
Aug 25, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1794.
sangaman
added a commit
that referenced
this issue
Aug 25, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. Fixes #1799. Fixes #1794.
sangaman
added a commit
that referenced
this issue
Aug 26, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708.
sangaman
added a commit
that referenced
this issue
Aug 26, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708.
sangaman
added a commit
that referenced
this issue
Aug 26, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708.
sangaman
added a commit
that referenced
this issue
Aug 26, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708.
sangaman
added a commit
that referenced
this issue
Aug 27, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708.
sangaman
added a commit
that referenced
this issue
Aug 27, 2020
This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708.
raladev
pushed a commit
that referenced
this issue
Aug 28, 2020
* feat(swaps): monitor pending payments before fail This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708. * test(sim): handle no force close for taker This modifies the simulation tests to account for the maker properly canceling the invoice for its incoming payment once its outgoing payment htlc expires. Rather than expecting the channel with the taker to maker payment to expire and force close, it expects the invoice to be canceled and for the channel to remain open. It ensures that the balances on the channel do not change.
rsercano
pushed a commit
that referenced
this issue
Sep 11, 2020
* feat(swaps): monitor pending payments before fail This monitors all swap client payments until their resolution without putting deals into `SwapRecovery`. Previously, if a call to send payment failed but the payment was still in pending status (as has been the case with Connext), then we would fail the swap deal and monitor the payment in `SwapRecovery`. This had several downsides, namely: 1. Since the deal is marked as having failed in the database, if xud restarts while payment monitoring is ongoing, it won't resume monitoring because it sees the swap as having failed in the database. We only recover swaps that were "active" at the time xud shut down. See #1799. 2. When a deal is failed, the maker order it attempted to swap re-enters the order book and is available to be matched again. However, since the payment for the original deal is still pending, it may still go through, meaning that the order can be "double filled" in such a case. See #1794. By monitoring all pending payments to their resolution, we ensure that we don't fail deals that wind up completing. This also fixes a case where the maker would not cancel its invoice when an outgoing payment would fail and the very first `lookupPayment` call would confirm that it had failed. Fixes #1799. Fixes #1794. Fixes #1708. * test(sim): handle no force close for taker This modifies the simulation tests to account for the maker properly canceling the invoice for its incoming payment once its outgoing payment htlc expires. Rather than expecting the channel with the taker to maker payment to expire and force close, it expects the invoice to be canceled and for the channel to remain open. It ensures that the balances on the channel do not change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
#1761 (comment)
The text was updated successfully, but these errors were encountered: