Leave staggered orders when exiting from dexbot-cli #148
Conversation
|
in this case, if you did want to cancel orders and leave a market, how would you do so? yes you could manually delete orders, but for staggered orders that could take a long time. |
|
#137 says "Staggered Orders should be left on the books when exiting dexbot-cli with ctrl+c", I implemented exactly this. For leaving a market and cancelling all orders I think better to have a CLI option for that, example: |
|
There are reasons to exit dexbot-cli. One is upgrading the software. Sometimes you need reboot. Also if you need to kill dexbot because of a bug, it isn't convenient if it cancels all orders at restart. |
bitphage
force-pushed
the
137-prevent-staggered-orders-cancel-on-ctrl-c
branch
2 times, most recently
from
6e808c0
to
b8c8b18
Compare
|
OK, I finally changed a PR to not touch the previous logic of orders placement. I also got rid of code-duplicating clean_exit() and made it a wrapper of stop(), and added appropriate handling in stop(). |
1. Change how INT/HUP/TERM signals are being handled. Instead of invoking worker.stop job, define a separate worker.clean_exit job which is a wrapper on stop(). 2. Add clean_exit kwarg to worker stop() method. Thus, each strategy can separately define a handler for clean_exit. 3. In staggered_orders.py strategy define clean_exit() method which doesn't cancel orders but leaves them. Closes: Codaone#137
bitphage
force-pushed
the
137-prevent-staggered-orders-cancel-on-ctrl-c
branch
from
b8c8b18
to
6c6eb5e
Compare
|
I moved the fix to #161 |
Change how INT/HUP/TERM signals are being handled. Instead of
invoking worker.stop job, define a separate worker.clean_exit job which
actually do the same things as stop(), but instead of cancel_all() it
calls clean_exit() method. Thus, each strategy can separately define how
it should handle exit signals.
In staggered_orders.py strategy define clean_exit() method which
doesn't cancel orders but leaves them.
Because of (2), staggered_orders.py at the every worker startup
should not try to place any orders from database. Since previous run
things on the marked may drastically change and just placing old orders
is just an error. So, just recalculate everything after worker startup
and place newly calculated orders.
Closes: #137