node-binance-api: Problems with Depth Cache
I’ve been running Depth Cache for a while now. And the code broke two times, these are the errors:
node-binance-api.js:280
for ( obj of depth.b ) { //bids
^
TypeError: depth.b is not iterable
node-binance-api.js:603
for ( let depth of messageQueue[symbol] ) {
^
TypeError: messageQueue[symbol] is not iterable
I think Depth Cache has some issues at the moment. Or is it my fault? This is the code I’m using
binance.websockets.depthCache(socketArray, function(symbol, depth) {
let bids = binance.sortBids(depth.bids);
let asks = binance.sortAsks(depth.asks);
let bid = binance.first(bids);
let ask = binance.first(asks);
prices[symbol] = prices[symbol] || {}
prices[symbol].ask = parseFloat(bid),
prices[symbol].bid = parseFloat(ask)
});
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 24 (8 by maintainers)
Commits related to this issue
- Merge pull request #33 from jaggedsoft/master Better error handling on API requests. Thanks hems! — committed to jaggedsoft/node-binance-api by deleted user 6 years ago
- Merge pull request #100 from keith1024/issue-33-depth-cache-message-queue [#33] ensure depth cache message queue exists — committed to jaggedsoft/node-binance-api by deleted user 6 years ago
The ‘if’ that i added revolved completely the issue in my software. We are still developing using this library and the error did not happen again 😃
Still, i hope someone test it too! Pretty fast to test it if you already have the request implemented.
Thank you very much @josepgomes If that code is tested and working I can include it in the next release
@jmarto Excellent, thanks for the update. That makes sense that it would cause the same error. If you delayed that second call however, it would work, but then you’d have two sockets open providing duplicate data.
@jaggedsoft Perhaps as a more bulletproof fix, we can discuss having the API throw a more descriptive error when:
websocketsfunctions.I say technically above as it would only detect exact duplicate subscriptions as an error. ie.
The alternative to point 1, if we don’t want to restrict users to only a single point of subscription, would be to just attach their
callbackto the already existingWebSocketinstance.What do you think?
It wasn’t. I was initially passing in as per my edit with simply
['XRPBTC','LTCBTC']. But would you believe that it has just decided to work with v0.4.11? Can’t figure out why, but I’m sure it was my fault. Sorry to bother! Thanks for following up so quickly.@jmarto @jaggedsoft I’ll have a look at this right now. Will provide updates on my findings as soon as I have any.
@jmarto Could you please provide a snippet of what your call to
websockets.depthCachelooks like, along with what your first parameter (symbols) is? Thanks.Hi,
Don’t know if this is the perfect way to correct this problem, but can help a lot of people until official fix is released:
line 603
To
PS: It worked for me, no more errors 😃