Got this message: Websocket Error without any other provided context
[WinError 10054] An existing connection was forcibly closed by the remote host on_close
any idea what’s going on? this is the first time that this has happened to me running an open websocket connection.
10054 is a WebSocket protocol error that basically says for some reason the host closed the connection. This could be for a variety of reasons, so it would help if I could get some more information. Are there any additional logs you can show me, a timestamp you can give me, or (best of all) can you reproduce the error?
still having this issue – im wondering if its because I have an open websocket connection and am receiving notifications through the tradovate app on my smartphone at the same time, even though I don’t actually have the app open?
@Alexander I’ve noticed that my connection remains stable and open for many hours, after which it suddenly gets closed by the host. could getting pulse notifications at the same time as having an open websocket cause this? Reminder that I do not have the app open on my phone when this occurs
I get similar problem yesterday,I check the log ,It may be has 3 session in the same time ,It will be kick off the first session,today I run my program hold day with one client open.
and I catch the error of socket error,It will be reconnect after a error of socket,remember you need sub the quote or chat after reconnect marker data socket
I discovered that it is not the problem with having Pulse open or on my phone. @Alexander can you let me know the situations in which the host would terminate a connection like this?
There are any number of reasons that a connection could be dropped. But no matter what, your code will ultimately have to deal with the connection being dropped as this scenario will eventually present itself with a program that is intended to run indefinitely.
I’d suggest running code when you get the close frame (a ‘c’ frame), or simply when you encounter a 10054. You would just re-instantiate your WebSocket and re-perform the auth procedure, then set up your previous listeners. If you do that you should be able to just reconnect when the connection gets dropped.
To clarify the nature of 10054 errors - these are just generic errors for websocket servers that says ‘Hey, we dropped your connection, sorry.’ You can see this error in all sorts of websocket implementations from windows applications to video games. It doesn’t mean anything necessarily other than a long running connection was dropped (usually because of inactivity or connectivity issues, plus browsers throttle long running tasks like heartbeats which could lead to this error).
Unless you’re having issues with some part of the program before the connection was dropped, simply adding a routine to catch the dropped connection and re-instantiate it should fix this issue.
I’ve noticed that it normally happens in the situation of the websocket being open for a while, and then me executing a trade via a POST request simulateously. could this be the reason why this is occurring: having a websocket open and simultaneously sending a post request?
I don’t think that they should be related, but if you request a new access token or something in the course of making the request, it would void your old access token (it will begin a new user session for you, like when you log in to the Trader app). If you had your websocket authorized using the old token, it would be booted off as an older session when that request goes out. Make sure to store your access token so you don’t have to keep requesting it for HTTP requests, or send your HTTP requests through the WebSocket instead.
If we renew token then also we need to do reauth on webscoket as well ? and we need to send user/synch request again as well ?
But if we are sending user/synch request again we are getting p-token
See excerpt from API documentation below. If you renew the token, it stays valid. If you do not renew the token, you will get a 429 error code… in that case, you will need a new access token and start all over with a usersync.
You get the p-token because you are doing a second usersync that is not needed. Think of p-token as a slap on the wrist telling you that you are doing something that you should not. This is their way of getting your attention.
Access Tokens have a natural lifespan of 90 minutes from creation. However, you can extend that lifetime by calling the /auth/renewAccessToken operation. It is advised that you call the renewal operation about 15 minutes prior to the expiration of the token.
Calling the accessTokenRequest endpoint successfully will start a new session on our servers. This session is tracked, and you are limited to 2 concurrent sessions. Once a third (or additional) sessions are created, the oldest sessions are closed. This can be problematic in the following situations:
Hi @Frik Thanks a lot for your kind response.
We call renewAccessToken only and it would give us new token so in that case do we need to reauthenticate WebSocket again and usersynch request again?
Would that be issue like we are placing trade and querying order from rest API as well sometime and that would disconnect WebSocket ?
When you renew the token it stays valid and there is no other action to be taken on the websocket since you are already connected.