Error: WebSocket is already in CLOSING or CLOSED state
See original GitHub issueAfter switching from subscriptions-transport-ws
in Apollo client, there is always error WebSocket is already in CLOSING or CLOSED state
after initialization in browser console.
Further Information
- graphql-ws: 5.6.2
- @apollo/client: 3.5.10
- Chrome: 99.0.4844.51
const wsLink = new GraphQLWsLink(
createClient({
url: 'ws://localhost:4000',
connectionParams: async () => ({
credentials: 'include',
authorization: await getAuthToken(),
}),
})
)
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (5 by maintainers)
Top Results From Across the Web
javascript - How to catch and deal with "WebSocket is already ...
i resolved this by checking the readystate property; if it equals to 3, close and reinitialize the websocket connection. then do a while...
Read more >WebSocket is already in CLOSING or CLOSED state. ERROR
WebSocket is already in CLOSING or CLOSED state means that the connection has been disconnected and data cannot be sent through this connection....
Read more >WebSocket is already in CLOSING or CLOSED state.
The log message seems to indicate that the client side javascript is attempting to close the socket when in fact the server has...
Read more >WebSocket - The Modern JavaScript Tutorial
It responds with “Hello from server, John”, then waits 5 seconds and closes the connection. So you'll see events open → message →...
Read more >How to fix error: WebSocket is already in CLOSING or ...
How to fix error: WebSocket is already in CLOSING or CLOSED state · Example 1: · Example 2: · Example 3:.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks, 5.6.3 have solved the problem.
Inspecting the callstack and taking a hint from your further comment - I suspect that the
connectionParams
is taking too long to resolve, causing the server to kick off the client respecting theconnectionInitWaitTimeout
.To solve it, simply increase the timeout on the server or speed up the
connectionParams
.The fix released in v5.6.3 stops execution after
connectionParams
if the connection was closed while waiting. Previously, the client was trying to send a message afterwards regardless, leading to the error in the browser’s console.