ExchangeNotAvailable hang time

[topherbuckley]

Binance.com's public REST API is unavailable in the states, but it's available in Japan, and most other places
whether or not you have an account with them.
You just need access to the public API for ohlcv candles (ie. Pricing data).

Originally posted by @macanudo527 in #159 (comment)

I just tested the geoblock from binance (call me curious), and it only really tells the user in the debug log, on the cli it just shows "resolving transactions" and appears to hang for a REALLY long time. I looked into it and it is looping for len(_TIME_GRANULARITY_DICT.get(exchange, _TIME_GRANULARITY)) * 9 * 10 seconds = 9 min. This doesn't seem like a great user experience to me, so I wonder if we can discuss the best alternative?

It looks like the ExchangeNotAvailable error experienced here is intended to catch a few other things than this geolock.

I see the extra if-logic for handling the _BINANCE exchange, so is it possible for a this geo-lock to result in a NetworkError or RequestTimeout as opposed to the ExchangeNotAvailable?

Would it be bad practice to parse the string from "msg" portion of the GET response?

I get the following "msg" that could potentially be parsed to exit earlier:

Service unavailable from a restricted location according to 'b. Eligibility' in https://www.binance.com/en/terms. Please contact customer service if you believe you received this message in error.

[macanudo527]

I think parsing the msg could prove to be too brittle. Binance could change this at anytime and then the code would no longer work.

If you are looking for a better experience, I would just move the if statement for Binance out of the if retry_count > 9 line so that it short circuits earlier. That could lead to false positives if the exchange is taking too long to respond though.

This was meant as a temporary fix until we can implement automatic market discovery which will eliminate this error completely.

Sorry I'm on the train at the moment. Maybe I can look at it later for more ideas.

[topherbuckley]

Yeah, I was also fearing that, and thus was hoping to access the 451 error directly from the HTTP response, which I would guess to be more robust. I mention a few more ideas in the PR comments if you want to follow up in either place when you have time.