DeviaVir / zenbot

Zenbot is a command-line cryptocurrency trading bot using Node.js and MongoDB.
MIT License
8.22k stars 2.04k forks source link

Some trades are missed on exchange and completed in bot #1423

Open kongres opened 6 years ago

kongres commented 6 years ago

System information

Hi! Firstly, Thank you for the great bot! I'm working with this bot and I've noticed one strange behavior. Some trades are not appearing on Poloniex. The following screenshot shows this issue: image

I didn't check if it placed any order during this time, but in the end no any record about this activity in history on Poloniex. It happens not always. Most trades are fine and have records in history on Poloniex.

I'm not sure but maybe it is related with multi-instances? I've created configs files for each instance. And run the bot in two different instances with two different configs.

kongres commented 6 years ago

Happened again: image

Primea1 commented 6 years ago

I've had this issue on binance with ETH/USDT. It said it completed a trade, but it never did and just kept saying "sold" over and over. then the bot stopped working completely.

kongres commented 6 years ago

I've added logging on trade method in exchange.js and nothing. It doesn't call the method when show these messages... Checking other places...

station384 commented 6 years ago

I've gotten this too. while working out a bug in hitbtc and I think I may know a way to reproduce the condition that this happens.

This occurred during adjustment of the price of an order, and how the exchange logs orders. It didn't happen all the time but enough that I could narrow it down and work around it. This is HitBTC specific, but other exchanges may work and report the same ways, or similar. HitBTC can take up to 30 seconds for an order to be logged as cancled, changed or placed. They seem to have 2 different queues going, the live trade, and the order log and when you issue a command it happens immediately in live, but when you use the API to scan the status of the order, it will use the order log and it will report order not existing, or order canceled for 1-30 seconds, then it will start reporting the correct value.
This delay if it isn't handled correctly can confuse zen. Depending on the exchange, it may report closed sending that to the engine, which would then remove it out of the trade queue and forget that there is a trade still happening. I have seen different responses for hitbtc under these conditions, closed, not found, and canceled, then flipping to open once the log is complete.

My solution was to ignore the noise and keep retrying every few seconds up to a time limit. It wasn't perfect, but it seemed to work for the most part.

I think a true solution would be for zen to periodically ( at start, and every 30 seconds or so) query the exchanges and check reality with what it thinks it should be and consolidate the lists between internal and what the exchange reports. This would prevent any outlier conditions that are not handled by the api extension.

Haehnchen commented 6 years ago

same here on gdax. as i see api errors are not catched in the right. for gdax i see we should add some console.log on api errors. also the retry condition should be take in account. "extensions/exchanges/gdax/exchange.js".

as currently each exchange implemention is handling retry on its one. maybe we should look add the binance implemention. there we force retry alot

kongres commented 6 years ago

I've found two bugs in code which look like reasons of this issue. I've fixed locally and testing it now. Looks like working. But I will wait one more day and will try create PR to fix them

Haehnchen commented 6 years ago

@kongres any feedback; worked your solution? its really annoying ;)

kongres commented 6 years ago

@Haehnchen
Sorry for small delay. Main project kill all my time. I needed to fix the following: https://github.com/DeviaVir/zenbot/pull/1457 https://github.com/DeviaVir/zenbot/pull/1458 and one more issue which already fixed https://github.com/DeviaVir/zenbot/commit/84f383afad60c1780c4476a7ea308f5e8d1e8c8a

Now all works fine

vitorego commented 6 years ago

hi, same here using gdax.