thraneh
commented
2 years ago A temporary solution may be to "silence" the non-final request status. This can now be done by using the --silence_non_final_order_ack=true command-line flag.
It may be a temporary solution for Kraken Futures where we often see disconnects or experience timeouts.
NOTE! It will not deal with the case where a response is lost due to disconnect or timeout yet the exchange received the message and rejected it. (For this scenario we might never get any updates on other channels, as described above.)
This is unclear because TIMEOUT is not a final request state.
The immediate thought is to simply suppress this update and wait for the gateway to send subsequent final request states (ACCEPTED or REJECTED).
This is a scenario that can happen for many gateways where order actions are sent on one connection and order updates may arrive on another connection. A timeout (or disconnect) could occur on the order action channel and the order update could arrive immediately after. There's also the scenario where the order request is rejected and an order update may therefore never arrive on the other channel. For these scenarios a download must be requested (another request with potential for timeout/disconnect) before one can confirm it's rejected.
This is related to
38
39