Timeout for Limit Buy Order

[rel-s]

A limit buy order might fail to get 100% fulfilled. In that case it would be best to implement some timeout mechanism, so the bot can automatically return to scouting mode.

[edeng23]

The right way to implement this idea is to delete the pending order, but stay on USDT until a good trade comes about. I definitely don't want to return the the previous coin or jump to a random coin. This would break the bot's premise which is never to return to a coin if it means having less than of it than before.

[tinchogon34]

Would love to have this feature. I always end with a stuck open order. Any directions about how I could help coding this?

[luponata]

Would love to have this feature. I always end with a stuck open order. Any directions about how I could help coding this?

Yep, something like:

how_much_wait = 10 #(seconds because sleep arg)
iter = 0

while stat[u"status"] != "FILLED":
            try:
                stat = self.BinanceClient.get_order(
                    symbol=alt_symbol + crypto_symbol, orderId=order[u"orderId"]
                )
                time.sleep(1)

                iter += 1
                if iter == how_much_wait:
                    cancel_order_method(order_id)
                    raise Exception("Time is money!, order timeout")

            except BinanceAPIException as e:
                self.logger.info(e)
                time.sleep(2)
            except Exception as e:
                self.logger.info("Unexpected Error: {0}".format(e))

or going with maker orders :/

[midnightzigzag]

This bug causes another bug that the program can't gracefully recover from. If this happens and the user closes the program with Ctrl+C and restarts, it enters a death-loop trying to sell the previous coin that it's already sold. The fact it's already sold and attempted to purchase another coin isn't saved. Only fix I've found is deleting the database and wiping all progress. Sometimes this happens as early as initialising the program, it doesn't even get 5 seconds in before it's fallen over completely.

[ardgraft]

I would be happy to test this if someone could code this up?

[ardgraft]

There are some good suggestions coming through on Discord on how we could solve this. I have not verified any Binance API end points to allow some of these suggested actions, but some of the logic our friends are coming up with seem good. I agree with @edeng23 on not returning to the sold coin. To add, I think once a transaction has been made sell or buy, there is no going back. Unless the bot deems it a good trade during the next scout process of course. So, trying to summarize some key thoughts/points from everyone:

• We all agree that waiting for a limit order to conclude greater than X time is probably not helpful. As too much changes in the market during the wait time. If a timeout is the way forward, what that X timeout value should be is one to discuss. Perhaps allow this as a user.cfg item.
• If we agree to abort/cancel an order, are there API endpoints with Binance to allow that? (To verify)
• If we agree to abort a transaction before any part is filled or is filled partially, what fees would be incurred? Would this need to be factored into the calcs for the next scout? (To discuss)
• As @rel-s started this issue with, what happens in a partially filled order scenario? (To discuss)

[ghost]

I think the easiest solution is simply to use market orders. I see no reason to use limit orders for this type of bot. unless it's a pump and dump, we are setting stop losses or take profits, there's no reason. place the market buy, and move on as quick as possible.

[ardgraft]

I think the easiest solution is simply to use market orders. I see no reason to use limit orders for this type of bot. unless it's a pump and dump, we are setting stop losses or take profits, there's no reason. place the market buy, and move on as quick as possible.

I did read somewhere on discord perhaps, that this was discussed and for some reason Market order was not a good idea because (Need to find Discord discussion) ...

[ghost]

well, binance api has order types to handle this automatically for limit orders. currently the timeInForce is set to GTC (Good Til Canceled) there are two others FOK (Fill or Kill) and IOC (Immediate or Cancel). Once you place one of those, you keep checking order status, if it's cancelled, then you place another order, otherwise when it's filled, you go back to scouting.

FOK will fill 100% of the order or cancel, IOC fill as much as it can and then cancel. IOC would be best for this bot as it will work with large orders. either way you need to loop, just with IOC you need to update the remaining qty and keep placing orders until it's gone (this usually only happens with whale orders)

[johannes-peeters]

I think the easiest solution is simply to use market orders. I see no reason to use limit orders for this type of bot. unless it's a pump and dump, we are setting stop losses or take profits, there's no reason. place the market buy, and move on as quick as possible.

Market order could defeat the purpose of the bot, which is today ensuring we will never end up with a lower amount of coins.

[AdrianoMartins]

What if we use the book (method get_order_book in Binance module) to get the price in the scout and change the order to market?

It will ensure the purpose of the bot, since the calculation will be done using the book and not the current value, and using market ensure the immediate execution.

[vaaski]

what is the recommended behavior in this situation? just wait until the order fulfills, delete the database or trade manually?

[rel-s]

We have timeouts now, might need some tweaks but I guess this issue can be closed.