-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Websocket Logic Refactor - start/stop mechanism #232
Comments
Hey @Trevypants, thanks again for that suggestion! I know back then I was looking for exact this behavior, but somehow I never sat down to change anything there, since nobody complained so far. Currently I'm reworking the project; your suggested changes will be part of version 3.0.0. Let me know if you have any further ideas that might be worth to integrate! |
Thank you :) I will make other issues if I can think of any extra ideas |
What pattern should I use to recover from cancellederror, I want to keep the socket open to monitor for executions on my account but it seems the CancelledError is always raised. |
What do you mean with "the CancelledError is always raised"? Could you please share the relevant lines. In v3.0.0 of the SDK, there will be the start/stop feature, as proposed here, meaning that you can start and stop the connection at any time. For the current versions of the SDK, you will need to instantiate the websocket client again. |
Sorry for the lack of clarity. This is what I did to get a basic example of an authenticated user execution socket up and running without seeing the program end with CancelledError. Please let me know if it is an acceptable pattern to follow until 3.0 is released, thanks for the help and work on this. I didn't need to instantiate the WebSocket more than once. I'm just starting to wrap my brain around asyncio, so I'm not sure if this pattern is acceptable.
|
One option would be to put the while loop into a separate function and run it until |
Describe the solution you'd like
I am working with the websocket client and I am missing the 'start/stop' control.
Starting
Currently the code is set that the moment you initialize the WS client, it opens a connection. However, I believe this logic is quite restricting since there will likely be scenarios where a user doesn't want to open the WS connection right away but have it on standby. An alternative would be to implement a
start
method (naming choice TBD) that will open the WS connection.Stopping
Currently the code is set that there is no way to stop the WS connection from the user side. When looking into the code, I see that the connection is fully stopped only when an exception occurs. When testing the WS client on my side, stopping the code with this behavior leads to multiple Runtime Errors. Having a
stop
method (naming choice TBD) that will close all WS connections would really help in this and will also add extra flexibility to the WS usage.Describe alternatives you've considered
I have implemented a hacky solution on my side with an example
start
andstop
method for the spot WS client. The code is shown below. A few points to note:keep_alive
variable (now a class attribute). Instead of manually cancelling the WS coroutine task, setting thekeep_alive
variable to False will allow the coroutines to end gracefully without needing to catch the asyncio.CancelledError exception.start
method that creates the WS task instead of it being on the object init() method.stop
method that stops the running WS connection by setting thekeep_alive
variable to False and then awaits the task. Since the value is set to False, the while loops will all end and the task will successfully complete instead of the original logic of waiting for an exception. This allows for graceful shutdown.start
andstop
method has been implemented to call the connectors'start
andstop
method.Additional context
Here is an example usage of my hacky solution :)
The text was updated successfully, but these errors were encountered: