Trailing Safety Order tries to cancel order, fails, then counts SO as filled (Paper Trading) #205
Replies: 7 comments
-
Could you post a screenshot of the deal details in 3Commas? I've seen during my own testing in the past that SO's could not be cancelled, however, in that case the order was (partially) filled at the same moment the script decided it should be cancelled (meaning the SO should be counted). |
Beta Was this translation helpful? Give feedback.
-
I certainly can. I'm attaching 2 screenshots. This isn't the first time it has happened and the case you brought up would make sense. Unfortunately, I don't see that any of the effected deals had any partial fills. Let me know if you need to see my bot details. Thank you! |
Beta Was this translation helpful? Give feedback.
-
FWIW, I was trying to backtrack the source of the problem in the code. That brought me to threecommas.py and the def for threecommas_deal_cancel_order (line 672). I was wondering if 3Commas had a delay between the api.request (line 677) and the cancellation of the order, if the expected "data" just below the api.request wouldn't see the "status_string" as "cancelled". By the time the script gets to the WARNING line in my first post the script reports that the status is Cancelled, but that is a little further down the line. Maybe the script should wait for a second or two for the order to cancel before checking the "status_string"? I don't know... I'm just tinkering around. |
Beta Was this translation helpful? Give feedback.
-
I'm thinking someting else, actually. In the first image you posted (thanks for that), the status of order 470698406 shows Cancelled. That makes me think about this line again: "cancellation of order 470698406 failed. Current state is Cancelled". Why does the script wants to cancel an order, of which the state is already cancelled...? This raises the question what has happened with order 470698406 before. Are you able to 'grep' that from the logfile? Was it cancelled before from the script and not administrated properly, was it cancelled from 3C website maybe? |
Beta Was this translation helpful? Give feedback.
-
Order 470698406 was created by the script three minutes before the attempt to cancel it:
Your question of why does the script want to cancel an order of which the state is already cancelled, led to my theory above. The script sends the api.request to cancel the order then immediately checks the "data" to see if there are any orders cancelled. If the 3Commas database doesn't show the order is cancelled yet on their side, the script continues past that section of code. The second line of the error in my first post shows that 3C is reporting a status of Active for the deal it just tried to Cancel:
By the time the script gets to the "def evaluate_deal_orders" section of trailingstoploss.py the 3Commas database has updated to a status of Cancelled. This section of the script is what is causing the Warning in the logs because the status is Cancelled and does not match the status of Filled:
|
Beta Was this translation helpful? Give feedback.
-
I see what you are thinking. Will need to check the code myself and see how and what. I'm out of the country for work and back end of next week, so will try to have a look when I'm back. |
Beta Was this translation helpful? Give feedback.
-
No problem. Thank you for the response and safe travels to you! |
Beta Was this translation helpful? Give feedback.
-
Hi,
I'm running into a problem with trailingstoploss_tp.py
While paper trading on 3Commas, the script follows the price action down and creates a safety order. When the price rises the script cancels the safety order, but doesn't think it has done so successfully. That would be fine, but it then reports that the safety order has been filled, even though it was actually cancelled. This error leads to the safety order tracking being incorrect and skipping the safety order entirely. Could this be a paper trading thing?
Here are some logs:
Thank you for any help!
Beta Was this translation helpful? Give feedback.
All reactions