[bug] DMS mis-configured at reload
Closed this issue · 12 comments
Api-server watch reports DMS setting not active whereas GUI shows the box ticked both before and after the reload.
2022-09-08_08-49-59.mp4
Thanks for the report! under review and should be addressed asap
Hey @pointops, in the recent releases, there was a change regarding the DMS mechanism, and to avoid things like network instability killing orders, now the dead-man-switch waits for one minute after close instead of an instant kill. Can you check it works on your side?
I'm also working on other improvements in the API to retry canceling orders if something goes wrong. Let's use this GitHub issue for updates.
Hi @tarcisiozf.
This issue points out a simple discrepancy of the DMS default config and its indication.
Re: Check of DMS delay
Not sure if able to.
I am not using the full Electron Bundled APP, if started throwing some sandbox access errors at me and the willpower to learn what they are is not there (omg).
Hosted mode (that is the Web-based user access, right?) - tried last year and stopped as it was under-developed. Possibly I read now somewhere it's been taken down these days?
What I am running is the Development mode on Debian/Ubuntu/WSL2 with GUI in chromium / Edge. For this, I don't think the DMS works at all with a simple reload (CTRL+F5) possibly it is not inteded to.
I tried shutting down the ~/bfx-hf-ui processes and that is when I get the AOs wiped and it seemed to work as advertised.
Need to get back to you after further study.
@pointops, thanks for the reply.
Yeah, the hosted version was out for some changes in the platform in general, but we are working on bringing it back up.
For your case, the DMS with a delayed kill-switch may not be a good fit. I'll add a suggestion in our backlog to allow users to customize the delay (or not delay it at all).
cc: @hm-bfx
The issue reported here remains, BTW. There is a logical inconsistency for the first launch between the DMS setting (false) and indicted selection on the check box (true).
This is a small GUI issue, but confusing a lot.
Recent log capture:
Clicking the checbox to OFF issues re-connect changing state to FALSE, which was the active state already.
REQUEST:
During start, read the DMS state from somewhere and use the value to populate the DMS check-box. If no current state found / or not available, default both the DMS logical state and check-box to the same value. (false + false | true + true)
For the moment, to make DMS work as advertised, user needs to recycle the selection to which there is no guidance or apparent reason to do so.
Stale issue message
The latest RC behaves the same,
Launches with DMS off but the modal Check-box = SELECTED.
Stale issue message
reporter elsewhere as fix in progress
Stale issue message