Missing sell orders because quantity doubles

[eppenga]

I am experiencing a similar issue as in #451 and in my case sometimes the quantity of the order doubles (it does not create double orders). Please see here an example of my log below, also for you @uhliksk and @habibalkhabbaz

At 10:58:49.935 the order is still in tact and shows a quantity of 3.29 SOL to be sold:

At 10:59:50.619 the quantity suddenly jumps to double (3.29 * 2 = 6.58 SOL), no additional buy orders were performed as you can see:

This then corrupts the sell order (because it only has 3.29 and is trying to sell 6.58 SOL) and all future orders leading to a failure to sell.

For the record, I am using the last version v0.0.90 (48865a0).

[chrisleekr]

Please export the log and upload it here. So can see what exactly happened.

[eppenga]

Sure, with pleasure. Luckily the issue was still in the log file, for your reference I have listed the IDs below so it is more easy to search through. Hope you find a solution!

10:58:49.935 - id=633169c9d7c6a3394960f22a - Order still in tact (quantity 3.29)
10:59:50.619 - id=63316a06d7c6a3394960f23a - Order doubled (quantity 6.58)

Logfile:
SOLBUSD-2022-09-26-15-09-53.zip

[habibalkhabbaz]

Hello @eppenga, @chrisleekr

I can see this from the log (locked value is equal to -3.29)
ID: 63316a08d7c6a3394960f23f

{
  "asset": "SOL",
  "free": 6.59,
  "locked": -3.29,
  "total": 3.3,
  "estimatedValue": 109.824,
  "updatedAt": "2022-09-26T08:59:50.548Z",
  "isLessThanMinNotionalValue": false
},

Explaination

I am sure this is happening because of the race condition between WebSocket and the following function:

binance-trading-bot/app/cronjob/trailingTrade/step/handle-open-orders.js

Line 56 in f4bd6f6

const accountInfo = await updateAccountInfo(

The expected behavior:

1. Order canceled successfully.
2. Account balances updated from processSuccessfulSellOrderCancel (using addition & subtraction operation)

"asset": "SOL",
"free": "3.30000000",
"locked": "0.00000000"

3. Received account balance update from WebSocket later

"asset": "SOL",
"free": "3.30000000",
"locked": "0.00000000"

The actual behavior (which is happened here):

1. Order canceled successfully.
2. Received account balance update from WebSocket

"asset": "SOL",
"free": "3.30000000",
"locked": "0.00000000"

3. Account balances updated from processSuccessfulSellOrderCancel (using addition & subtraction equation)

Free = 3.30 + 3.29 = 6.59
Locked = 0 - 3.29 = 3.29

"asset": "SOL",
"free": "6.59000000",
"locked": "-3.29000000"

@chrisleekr do you have any suggestion to improve this ?

[chrisleekr]

@habibalkhabbaz

I had some thoughts.

I think we shouldn't use updateAccountInfo at all. If we try to calculate anything manually, it can give the bot chance to make mistakes because of the race condition.

We should replace any place using updateAccountInfo to getAccountInfoFromAPI. I don't think it will be a burden on API usage.

Thoughts?

[habibalkhabbaz]

@habibalkhabbaz

I had some thoughts.

I think we shouldn't use updateAccountInfo at all. If we try to calculate anything manually, it can give the bot chance to make mistakes because of the race condition.

We should replace any place using updateAccountInfo to getAccountInfoFromAPI. I don't think it will be a burden on API usage.

Thoughts?

@chrisleekr

Yeah, to be honest, the same idea comes to my mind.

We should use getAccountInfoFromApi as we did with the open orders. I think it will not affect the API usage.

[habibalkhabbaz]

Hello @chrisleekr, @eppenga

I just pushed a pull request to solve this.

[eppenga]

Thank you @habibalkhabbaz ! Much appreciated!

[eppenga]

Just installed the new version, thank you, will let you know if it happens again, but don't think so looking at the code!