NaN returned during exchange maintenance

[sanket-k]

Step 1: Have you search for this issue before posting it?

yes

If you have discovered a bug in the bot, please search our issue tracker.
If it hasn't been reported, please create a new issue.

Step 2: Describe your environment

• platform: Docker - latest build(Digest:sha256:3e8fe20bf6aaad9095e1ba0924ce2af3368cc55d1fe41eebb546a73a124fb77f)
• Operating system: ____
• Python Version: _____ (python -V)
• CCXT version: _____ (pip freeze | grep ccxt)
• Branch: Master | Develop
• Last Commit ID: _____ (git log --format="%H" -n 1)

Step 3: Describe the problem:

the exchange binance was under maintenance from 2020/04/25 02:00 AM (UTC) - 06:00 (UTC) - https://binance.zendesk.com/hc/en-us/articles/360042668671-Binance-System-Upgrade-Notice-2020-04-25-

observed that the bot returned nan% for profit in /status, and the /performance field was empty.

note: Also in the earlier builds this response wasn't present.

If the exchange is down could we return the exchange is under maintenance rather than nan, or previous values??

[xmatthias]

how can you determine reliably that the exchange is down?

I don't think that CCXT has a method for that - so the only way to determine this is that calls fail - which can also have different reasons (like your network...) is therefore not reliable.

Unless we have a way to determine that reliably, i don't think this can be solved.

[sanket-k]

correct me if I am wrong, i dint seem to face this issue in an earlier build prior to feb ..how was the issue handled then ?

[xmatthias]

identically...
I assume you didn't press /status table while binance was down ... :) and values do return automatically once the exchange is back up, so to be honest, i don't really see this as a problem.

[hroff-1902]

the point here, in my opinion, is to print something more user friendly instead of 'technical' "nan%"

[xmatthias]

well but what's the alternative? assuming "exchange down" while you don't know for sure?

maybe it's not the exchange, just your connection - or this pair that's currently not tradable?

[hroff-1902]

"No data" / "N/A" (this does not add more info, though. not verbose enough) / "No data from exchange" (this is verbose, but can be too long for telegram output)

[sanket-k]

well, luckily I did have an other instance running in parallel with feb build

ed9b989d5f95
docker - digest ->
sha256:8037ec586694ee56dcdb84b957f984ed804350561d89d6945e88070e2d265b9e
and i did try /status and received a response

maybe this can be tried during the next maintenance ?

so, i was wondering if i missed something?

also, I would agree with @hroff-1902 maybe a ex.dn response would help rather than nan%

[xmatthias]

but printing ex.dn assumes it's the exchange that has a downtime - which (as mentioned above) is not necessarily the problem.

That's easy to say as you KNOW it was down ...

But all the bot knows is that a network call failed. There's many things that can be the reason for that - the exchange downtime is only one of these - and most often not the most likely.

So unless we have a way to RELIABLY determine that the exchange was down (which has to work for all exchanges!), freqtrade will not suggest that's the case as it cannot be sure, but is only guessing.

Also, the docker build won't really help ... best run /version to get the version of the bot.

[sanket-k]

Yeah, that is a good point,

so could we use ex.dn for atleast all exchanges which return the response of exchange is under maintenance, i think ccxt supports that with fetchStatus(), atleast that would cover a lot of the users i think.

as for the build, not sure it would be very helpful (this was my response)

[xmatthias]

well the change that's most likely related is the change to the price caching for RPC methods.

Now I think it's better to show "nan" than to keep the price around "forever" and report that price during an exchange downtime - as price can do "funny things" right after downtimes sometimes - so it's not really representative of the problem.

Anyway, it's noted as an enhancement to RPC - and I've labeled it with "Good first issue" - as i think the complexity of this is not high, and anyone trying to get their feet wet in contributing to Freqtrade is more than welcome to give this a try (we will support in case of problems - a draft PR shall be used to collaborate / investigate issues).

[av1nxsh]

hey, i am new to git
which command gives the status of the exchange and how do i test my code for maintenance test case

thank you.

[xmatthias]

there is no command for this at this moment - and testing for this properly is rather difficult - unless the exchange is "really" down.

Also, it might be difficult to implement as not all exchanges will have this endpoint - but for freqtrade, we'll need to handle all cases.

[werkkrew]

Is this still considered a valuable "good first issue"?

[xmatthias]

kindof - yeah ... although it's a more advanced first issue (good to start with freqtrade, but not good for programming novices), as i think we'd want to check the "exchange status" endpoint as well.

[Ali7425]

So is this still an issue that is still being worked on? If so how can I work on it>

[xmatthias]

well in theory - sure (it's an old issue - and functionality / code complexity / ... changed quite a bit ...).

in practice i'm not sure it's going to be a "valueable" enhancement (from a user perspective).
Of the supportes exchanges, only 2 exchanges actually support a "fetchStatus" call (binance, okx) - so for all others we'd have to assume it's up all the time - so only a fraction of freqtrade users will actually see this.

it's also not 100% clear how behavior should be in case of a confirmed downtime (we shouldn't assume it's down from failing requests ...) - and what this should include (only telegram? what about the api?)

If you intend to look at this - more than happy to discuss or have a look at something.
I'd however suggest you first have a good look through the codebase, have a look at what might be a way to handle this - and then post findings here so we can discuss how it should best be approached (also rough draft PR can be an option to discuss while seeing code).
Before that (we know how to approach this) - i wouldn't invest too much time into this - as exchange downtimes are handled gracefully afaik - it's just that not everyone likes a "nan" (which we put there intentionally, btw) - so it's not something that'll make anyone even 1c more in their trading journeys ... so from a "worth of time" investment, should be very low.

[stash86]

During exchange blackout (maintenance, bug, issue, doom etc), the bot will receive 0 volume candles. So you can already detect such issue by checking volume of past candles, which is better than relying on some API call to exchange's status(?) endpoint

[xmatthias]

During exchange blackout (maintenance, bug, issue, doom etc), the bot will receive 0 volume candles. So you can already detect such issue by checking volume of past candles, which is better than relying on some API call to exchange's status(?) endpoint

you can detect that after the fact - sure (also not reliably - 0 volume candles can have other reasons)

but not immediately / while it's happening / 1 minutes into the candle - 0 volume candles can have other reasons (low volume pair, shitty exchange, ...) - so that's definitely not a great indicator for "live" reporting of an exchange downtime.