I'm running gekko and it works great till now. But when I browsing gekko's code I found in the exchange/bitfinex.js (I'm dealing with that exchange) the getTrades is implemented as:
...
Trader.prototype.getTrades = function(since, callback, descending) {
......
if(since)
path += '?limit_trades=2000';
const handler = cb => this.bitfinex.trades(path, this.handleResponse('getTrades', cb));
retry(null, handler, processResponse);
......
}
...
It looks like value of "since" timestamp is skipped and it's just used to add a limit_trades=2000 to the API call. I tried to debug the code and that API call never returned entries more than 100.
I understand value of "since" is discarded because it's not supported by exchange, but what will happen if there's a flood of trades, say the trade rate reaches 1000/seconds. Given the getTrade API is call every 20 seconds by default, it looks like gekko will have a difficult time to generate correct candle in that case.
Could you guys please clarify if my speculation above is correct? It raises some concern about correctness of the trading bot .
...
Trader.prototype.getTrades = function(since, callback, descending) {
......
if(since)
path += '?limit_trades=2000';
const handler = cb => this.bitfinex.trades(path, this.handleResponse('getTrades', cb));
retry(null, handler, processResponse);
......
}
...
It looks like value of "since" timestamp is skipped and it's just used to add a limit_trades=2000 to the API call. I tried to debug the code and that API call never returned entries more than 100.
I understand value of "since" is discarded because it's not supported by exchange, but what will happen if there's a flood of trades, say the trade rate reaches 1000/seconds. Given the getTrade API is call every 20 seconds by default, it looks like gekko will have a difficult time to generate correct candle in that case.
Could you guys please clarify if my speculation above is correct? It raises some concern about correctness of the trading bot .