Skip to content
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

SubscribeAlerts #864

Open
kilrau opened this issue Apr 2, 2019 · 9 comments · May be fixed by #2023
Open

SubscribeAlerts #864

kilrau opened this issue Apr 2, 2019 · 9 comments · May be fixed by #2023
Assignees
Labels
enhancement New feature or request grpc gRPC API P2 mid priority
Milestone

Comments

@kilrau
Copy link
Contributor

kilrau commented Apr 2, 2019

This issue is about implementing a new SubscribeAlerts event stream for generic alert events. Here the current description of the status.

@kilrau kilrau added enhancement New feature or request grpc gRPC API labels Apr 2, 2019
@kilrau kilrau added this to the 1.0.0-sprint.14 milestone Apr 2, 2019
@kilrau kilrau assigned ghost and sangaman Apr 2, 2019
@kilrau kilrau modified the milestones: 1.0.0-sprint.14, 1.0.0-sprint.13 Apr 2, 2019
@kilrau kilrau changed the title [Concept] Channel unbalanced alerts Channel unbalanced alerts Apr 11, 2019
@kilrau
Copy link
Contributor Author

kilrau commented Apr 11, 2019

Since you are also on #680, I think it makes sense to also take this one @erkarl . I think we need a new SubscribeAlerts or more specific SubscribeChannelAlerts.

@kilrau kilrau modified the milestones: 1.0.0-sprint.13, 1.0.0-sprint.14 Apr 11, 2019
@sangaman
Copy link
Collaborator

We ought to discuss this on the call this week to settle on a good approach.

@ghost ghost added the question/tbd Further information or discussion needed label Apr 16, 2019
@kilrau
Copy link
Contributor Author

kilrau commented Apr 16, 2019

Recap from the call: check other projects for how they transport non-call specific alerts. Apart from that no show-stoppers so far @sangaman @erkarl

@ghost
Copy link

ghost commented Apr 24, 2019

Conclusion from the call: 1 call for generic events. Just type and description.

@ghost ghost removed the question/tbd Further information or discussion needed label Apr 24, 2019
@kilrau kilrau modified the milestones: 1.0.0-sprint.14, post-1.0.0 May 7, 2019
@kilrau kilrau unassigned ghost May 8, 2019
@kilrau kilrau removed this from the post-1.0.0 milestone Jun 11, 2019
@kilrau kilrau added the P3 low priority label Oct 9, 2019
@kilrau kilrau changed the title Channel unbalanced alerts SubscribeAlerts Jan 15, 2020
@engwarrior
Copy link
Contributor

Pls provide estimate for this task.

@kilrau
Copy link
Contributor Author

kilrau commented Feb 28, 2020

Still interested? @engwarrior

@kilrau
Copy link
Contributor Author

kilrau commented Nov 6, 2020

ExchangeUnion/xud-ui#34 depends on this

@kilrau kilrau added this to the 1.3.2 milestone Nov 6, 2020
raladev added a commit that referenced this issue Nov 19, 2020
* 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 <[email protected]>

* 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 <[email protected]>
Co-authored-by: Daniel McNally <[email protected]>

* 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 <[email protected]>
Co-authored-by: Daniel McNally <[email protected]>
Co-authored-by: Karl Ranna <[email protected]>
Co-authored-by: Le Premier Homme <[email protected]>
@kilrau kilrau added P2 mid priority and removed P3 low priority labels Dec 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request grpc gRPC API P2 mid priority
Projects
None yet
4 participants