[bug] Algorithmic orders have disappeared
2011 opened this issue · comments
I have just started using this, so apologies in advance if I missed something obvious (links to detailed tutorials appreciated).
Using 3.31.2 (AppImage).
I have an additional problem in that the charting doesn't work (it worked fine for a couple of hours, and now that widget shows nothing but a blank screen.
I have entered four (endless) Ping/Pong orders so far, and three of them have (at least partially) stopped working for one reason or another (I have monitored the orders while logged in via a browser).
For the first algorithmic order (two atomics), after a fill of the first buy order, I saw the associated sell order in my order list. But the fill of the second buy order did not create a sell order, and in fact, the algorithmic order disappeared from the Trading State Panel in bfx-hf-ui. The same thing happened to the second Ping/Pong order.
No fills have occurred for the third order, but it also has disappeared from the Algos tab in the Trading State Panel. The orders remain in the Atomics tab (and they still appear in the web interface with a "Ping/Pong" label).
I just entered the fourth Ping/Pong order, which so far (no fills) still appears in the Algos tab (with the Atomics visible, as well).
Note that /home/user.bitfinexhoney/algos.json shows "active": true for all four orders, while bfx-hf-ui only displays the last order in the Algos tab.
Any idea what could cause this (or how I could track it down)? The log file seems to have nothing except for "Checking for update" entries every half-hour.
see any 'meta-reloaded' ?
The GUI behaviour sounds consistent....
see any 'meta-reloaded' ?
No. Watching everything closely, I have noticed that (even brief) network glitches remove all of the algorithmic orders from bfx-hf-ui (no changes to the orders in the web interface). I now have (after reentering the algorithmic orders) 17 "active" algorithmic orders according to algos.json, but really have only four working at the moment. Does that file only get reset via a "Close Session"?
Any thoughts on making this more robust? I would think that after reconnection that bfx-hf-ui would query the outstanding orders and (at least in the cases where no executions have occurred) continue from the same point.
You are lucky then, check my timestamps.
N.B. i am not a developer, neither a team member nor able to contribute by creating fixes. Just complain here a lot.
There seem to be several types of 'disconnects' which trigger some unhealthy behaviour of the application. The 'meta reload' event is (my personal viewpoint) the meanest of them and has been utterly ignored for almost two years. With the other types, there was some honest work done, credit where due.
MR was sneaky because until recently it was not even noticed by the GUI.
Anyhow, something's cooking as we speak: https://github.com/bitfinexcom/bfx-hf-ui/pull/803/files, and that aims at the meta-reload. Good for you to join at a time when disconnect cases are apparently being looked at deeply than ever.
hi @2011 so:
Meta:reload is emitted after a server restart (i.e. when the connection is reopened) and we have a watchdog that waits 30 seconds before closing the connection and then try reconnecting to the bitfinex api again..
After successful reconnection, meta:reload is emitted and all of the locally running AOs are removed (local as in state variables in host, not the algo db). In algoDB, the active state of the previously running AOs is still true..
In the new behaviour (which hopefully will be available in March, 8/9) we read the algo DB for the AOs that have state active: true and we show them in a pop-up for the user to select either to resume/cancel them. If the user resumes them, we change nothing in algoDB (i.e. active state is still true) and we first cancel all the active atomic orders that were created by the AO (if any) and start the AO again and a local state variable is created in host and that state is continuously changed as the orders progress. However, if the user cancels them, we set the active state as false in algoDB and we don't run them (i.e. no state variables are created in host)
We are seeing if we can also change this 30s window (harcoded) into a preset variable. Therefore users will be able to increase this timer (may carry price slippage risks in case of long disconnects or high volatility) to reduce the amount of times meta:reload is triggered to a less sensitive amount (<= X minutes). We are also considering an "always restart" possibility, that would ensure AOs are resumed automatically basically bypassing the disconnection behaviour entirely.
Regarding the issue you mention about having excessive active orders in algos.json, could it be that some of the listed orders belong to another mode (e.g. sandbox)? If not it's definitely something we must look into. Nevertheless, after 3.31.4 this should be displayed for your selection on disconnection
Meta:reloadis emitted after a server restart (i.e. when the connection is reopened) and we have a watchdog that waits 30 seconds before closing the connection and then try reconnecting to the bitfinex api again..
I did see a Meta:reload (in 3.31.3) pop up after a disconnection, but it performed poorly when I used it (if I recall, it only offered to restart four of the six algorithmic orders I had active at the time, and two of those the program resumed in a basically unusable state - meaning I had to cancel them, and attempt to recover manually).
We are seeing if we can also change this 30s window (harcoded) into a preset variable. Therefore users will be able to increase this timer (may carry price slippage risks in case of long disconnects or high volatility) to reduce the amount of times
meta:reloadis triggered to a less sensitive amount (<= X minutes). We are also considering an "always restart" possibility, that would ensure AOs are resumed automatically basically bypassing the disconnection behaviour entirely.
I would like that. I don't know why I see so many disconnections (at least once a day, and most of them don't appear to come from an internet problem on my end). With Ping-Pong orders, the two negative outcomes from disconnects - missed opportunities and paying taker fees (possibly getting filled at a better price) don't appear particularly harmful.
Regarding the issue you mention about having excessive active orders in
algos.json, could it be that some of the listed orders belong to another mode (e.g.sandbox)? If not it's definitely something we must look into. Nevertheless, after 3.31.4 this should be displayed for your selection on disconnection
I have never used Sandbox Mode. The inactive orders (in 3.31.3) do all show "active": false in algos.json now, so that appears fixed.
more info in #813 (comment)
Stale issue message