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.

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 ?

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.

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

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?

"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)

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%

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.

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)

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).

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.

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.

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

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.