-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(rpc): runtime addcurrency for lnd & connext #1746
Conversation
This PR allows for adding Connext and Lnd currencies via the `AddCurrency` rpc call and have them available for trading immediately without requiring a restart of xud. In the case of Connext it merely registers the tokenaddress and currency symbol for the new currency with the existing ConnextClient, as we had previously done with Raiden. In the case of Lnd, we read from the configuration and use that to instantiate and initialize a new `LndClient` for the specified currency. Closes #1111.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ab03e59
to
3dd595e
Compare
3dd595e
to
0c60419
Compare
@raladev Would you mind rerunning your test with the latest from this branch? It should print the error as to why peer orders aren't getting removed, I don't understand why that's happening right now and that would help a lot. |
lib/swaps/SwapClientManager.ts
Outdated
this.swapClients.set(currency.id, this.connextClient); | ||
this.connextClient.tokenAddresses.set(currency.id, currency.tokenAddress); | ||
this.emit('connextUpdate', this.connextClient.tokenAddresses, this.connextClient.address); | ||
} else if (currency.swapClient === SwapClientType.Raiden) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should remove the raiden part since it's never going to be used and it would make the function more readable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also trying to work through why simulation tests are failing, so no rush. Moving this to draft status until I get to the bottom of it. |
@sangaman errors are occurred because of ETH disabling:
|
Can we push this one over the finish line too? @sangaman |
This just needs simulation tests to pass. Want to have a look? @rsercano |
Assigned both issues this will close to @LePremierHomme : |
# Conflicts: # lib/orderbook/OrderBook.ts # lib/swaps/SwapClientManager.ts
…or all connected peers
Nice! Ready4Review and end-to-end testing? |
@kilrau yes. |
84538d2
to
84ccbf2
Compare
Steps:
Actual result:
Note: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Above
Thanks for catching this @raladev , ping us when to test again @LePremierHomme |
Weirdness no 1:
This error is legit, it appeared because SER was added using Lnd as a swapClient, but Lnd does not support this currency, so -> swapClient for currency SER not found. Maybe we should add check for addcurrency command and Lnd Client (lnd client can be used only for LTC and BTC currencies)
Weirdness no 2:
Cant reproduce it with addcurrency branch. Marked as Fixed. Weirdness no 3:
getbalance command above doesn't show SER balance. Reproduced, it is a bug. Steps:
Actual result:
Note:
My own Weirdness |
7bd7d43
to
e52ba4f
Compare
@raladev the issue described in #1746 (comment) was fixed by e52ba4f so this branch can be re-tested. Regarding the described issue 3 in #1932 and #1746 (comment) - looks like the currency add is fine, but it is expected to already be defined statically in the unit converter. Any ideas? @erkarl @sangaman |
Once #1938 is merged we'll have access to the ethprovider via connext proxy. We can then query the contract address and get the decimal count dynamically. I suggest to hold off on adding more currencies to the currently static unit converter list. |
Ok, so looks like this PR just awaits final approval regarding the e52ba4f fix for #1746 (comment), from both @raladev and @erkarl. |
Current state:
|
Removed the closing statement for #1888 . We don't need vector for this, we just need #1054 and just bumped prio for this, @sangaman already has a PR up that fixes it: #1904
As just discussed, let's leave the closing statement here and please open a new
As just discussed, this is most likely an unrelated bug. @raladev please open a bug issue with as many details as you can get from your env. I observed the same behaviour a while ago on one of my environments and was not able to reproduce it ever since. Must be some edge case bug. |
The code looks good and passes some quick manual tests for me. No reason to hold this up any longer. Thanks to @LePremierHomme for figuring some of these lingering issues out. |
* feat: removeorder output changed to a more meaningful message (#1526) * fix(p2p): don't reconnect peers when pool closed (#1965) This ensures that we don't attempt to reconnect to peers that have disconnected from us after we have started closing the p2p pool. This may help prevent scenarios where we unintentionally attempt to reconnect to peers after shutting down xud. > Should be tested against [#1668 (comment)](#1668 (comment)) @raladev re-connection after shutdown is disappeared, but my xud still can not be gracefully terminated, it waits something: ``` 28/10/2020 05:17:43.164 [CONNEXT] trace: sending request to /balance/0x69C3d485623bA3f382Fc0FB6756c4574d43C1618 ^C28/10/2020 05:17:44.087 [GLOBAL] info: XUD is shutting down 28/10/2020 05:17:44.088 [LND-BTC] info: new status: Disconnected 28/10/2020 05:17:44.089 [LND-LTC] info: new status: Disconnected 28/10/2020 05:17:44.090 [CONNEXT] info: new status: Disconnected 28/10/2020 05:17:44.093 [P2P] debug: Peer 03ece33a30db1dbce4b62fa96a5e9541138a24997ef5672eebed2d332270e39542 (OzoneYellow): closing socket. reason: Shutdown 28/10/2020 05:17:44.095 [HTTP] info: http server has closed 28/10/2020 05:17:44.096 [RPC] info: gRPC server completed shutdown 28/10/2020 05:17:44.097 [P2P] trace: Sent Disconnecting packet to 03ece33a30db1dbce4b62fa96a5e9541138a24997ef5672eebed2d332270e39542 (OzoneYellow): "{\"body\":{\"reason\":9},\"header\":{\"id\":\"95133be0-1917-11eb-b75b-73d0f0278756\"}}" 28/10/2020 05:17:44.109 [ORDERBOOK] debug: removed all orders for peer 03ece33a30db1dbce4b62fa96a5e9541138a24997ef5672eebed2d332270e39542 (OzoneYellow) 28/10/2020 05:17:44.118 [GLOBAL] info: XUD shutdown gracefully ``` * feat(lnd): change gRPC client options * fix(connext): not enough balance for closechannel (#1963) This introduces better error handling for Connext when using `closeChannel` to remove funds from a Connext channel and specifying an amount to remove that is greater than the available balance. * feat: reserved capacity checks on PlaceOrder (#1949) This rejects orders that would put our total reserved balance over our total capacity for either the outbound or inbound currency. The sum of the inbound & outbound amounts for a newly placed order are added to the amounts reserved by open orders, and if either of these amounts exceed the corresponding capacity then the request to place the order is rejected. An exception to this are inbound limits for Connext currencies, since we have the ability to dynamically request additional inbound collateral via our "lazy collateral" approach. It is still possible for market orders to cause our open orders to exceed our capacity. This is a difficult problem to avoid entirely, as the price that market orders will execute at is unknown until the execution is complete. Even if we simulate the matching routine, we won't know which matches will succeed until we attempt a swap. Instead, we generously assume that market orders will execute at the best quoted price for purposes of these capacity checks. For users that simultaneously place limit orders and market orders for the same currencies, it should be made clear that market orders may use up their available balance needed for their limit orders to succeed. Closes #1947. * fix(cli): openchannel assertion error for string amount (#1950) Fixes #1643. * feat(swapclient): auto init wallets on xud unlock (#1973) This adds a new feature to xud to automatically attempt to create a wallet for any new swap client configured after an xud node has been created. Effectively this only changes the behavior for lnd clients, as this is already the existing behavior for Connext. The process for initializing has now been standardized instead of the ad hoc approach used previously. If xud tries to unlock an lnd node and gets an error message indicating that the wallet has not been created, then it will generate a client & currency specific seed mnemonic using seedutil and call `InitWallet` with that seed and the existing xud password, such that the wallet funds and node identity for the new lnd client can be unlocked and restored along with the rest of lnd. Closes #1929. * feat(rpc): runtime addcurrency for lnd & connext (#1746) Co-authored-by: Le Premier Homme <interjoint1@gmail.com> * refactor(rpc): rename reserved TradingLimits fields This renames the `reservedOutbound` and `reservedInbound` fields on the `TradingLimits` call to `reservedSell` and `reservedBuy` respectively. * fix(rpc): no success if no channels to close (#1689) (#1942) Co-authored-by: rsercano <ozdemirsercan27@gmail.com> Co-authored-by: Daniel McNally <mcnallydp@gmail.com> * fix: tls certificate check on startup (#1510) * fix: alias missing in streamorders (#1725) (#1962) * fix(lnd): handling hold invoice check errors (#1969) This adds better error handling for when the test calls to verify lnd hold invoices are available fail due to connectivity reasons. Previously any error that occurred at this step would cause us to set lnd's status to `NoHoldInvoiceSupport` including connection issues. There was also a bug that caused us to try to set the status to connected even when a hold invoice status check failed. This could result in the unusual behavior of status going to `Disconnected` upon a call failing due to the grpc `UNAVAILABLE` error status, then being set to `NoHoldInvoiceSupport` and then to `ConnectionVerified`. Now we only set `NoHoldInvoiceSupport` when the test calls fail for a reason other than `UNAVAILABLE`, and we only set the status to `ConnectionVerified` when the hold invoice calls succeed. Closes #1968. * feat(lnd): SendPaymentV2 This migrates the call we use to send payments with lnd from the deprecated `SendPaymentSync` to `SendPaymentV2` which allows for multi path payments, among other improvements. As part of this change, the lnd proto files have been updated to their v0.11.x versions and the version of lnd used in simulation tests has been updated to v0.11.1 as well. Closes #1590. * Revert "feat: removeorder output changed to a more meaningful message (#1526)" * fix: use regtest instead of regnet arg This fixes a bug where the xud flag to set the network was incorrectly configured as `regnet` when it should be `regtest` to match what xud expects. * fix(lnd): don't calculate negative capacities This fixes a bug in the logic for calculating the inbound & outbound amount/capacity totals. We subtract the channel reserve amounts from the balances when determining how large a payment the channel could support, however we should not end up with a negative number. * feat: new grpc call for subscribring alerts such as low balance (#864) * fix: changes removeorder output to a more meaningful message (#1526) (#1986) Co-authored-by: rsercano <ozdemirsercan27@gmail.com> Co-authored-by: Daniel McNally <mcnallydp@gmail.com> Co-authored-by: Karl Ranna <karl@karlranna.com> Co-authored-by: Le Premier Homme <interjoint1@gmail.com>
This PR allows for adding Connext and Lnd currencies via the
AddCurrency
rpc call and have them available for trading immediately without requiring a restart of xud.In the case of Connext it merely registers the tokenaddress and currency symbol for the new currency with the existing ConnextClient, as we had previously done with Raiden.
In the case of Lnd, we read from the configuration and use that to instantiate and initialize a new
LndClient
for the specified currency.Closes #1111.
EDIT by @kilrau : closes #1538