WebSocket with close code 1006
I'm trying to debug a weird intermittent issue where the client sometimes is not able to create/connect to the websocket.
I have a simple setup:
const ws = new Client(`ws://${vsUri}`, {max_reconnects: 0})
ws.on('open', () => {
console.log('its open')
})
ws.on('error', (e) => console.log(e)) // never called
Problem is, sometimes the 'open' is never called. I managed to monkeypatch into the rpc-websockets source code to gather more info, and I found out that ws.socket stays in the following state:
WebSocket {
_events:
{ open: { [Function: onOpen] _listener: [Function] },
message: { [Function: onMessage] _listener: [Function] },
error: { [Function: onError] _listener: [Function] },
close: { [Function: onClose] _listener: [Function] } },
_eventsCount: 4,
_maxListeners: undefined,
_binaryType: 'nodebuffer',
_closeCode: 1006,
_closeFrameReceived: false,
_closeFrameSent: false,
_closeMessage: '',
_closeTimer: null,
_extensions: {},
_protocol: '',
_readyState: 0,
_receiver: null,
_sender: null,
_socket: null,
_bufferedAmount: 0,
_isServer: false,
_redirects: 0,
_url: 'ws://redacted:xxx',
_req:
ClientRequest {
_events: { error: [Function], response: [Function], upgrade: [Function] },
_eventsCount: 3,
_maxListeners: undefined,
output: [],
outputEncodings: [],
outputCallbacks: [],
outputSize: 0,
writable: true,
_last: true,
upgrading: true,
chunkedEncoding: false,
shouldKeepAlive: true,
useChunkedEncodingByDefault: false,
sendDate: false,
_removedConnection: false,
_removedContLen: false,
_removedTE: false,
_contentLength: 0,
_hasBody: true,
_trailer: '',
finished: true,
_headerSent: true,
socket:
Socket {
connecting: false,
_hadError: false,
_handle: [TCP],
_parent: null,
_host: null,
_readableState: [ReadableState],
readable: true,
_events: [Object],
_eventsCount: 6,
_maxListeners: undefined,
_writableState: [WritableState],
writable: true,
_bytesDispatched: 228,
_sockname: null,
_pendingData: null,
_pendingEncoding: '',
allowHalfOpen: false,
server: null,
_server: null,
parser: [HTTPParser],
_httpMessage: [Circular],
[Symbol(asyncId)]: 64,
[Symbol(lastWriteQueueSize)]: 0,
[Symbol(bytesRead)]: 0 },
connection:
Socket {
connecting: false,
_hadError: false,
_handle: [TCP],
_parent: null,
_host: null,
_readableState: [ReadableState],
readable: true,
_events: [Object],
_eventsCount: 6,
_maxListeners: undefined,
_writableState: [WritableState],
writable: true,
_bytesDispatched: 228,
_sockname: null,
_pendingData: null,
_pendingEncoding: '',
allowHalfOpen: false,
server: null,
_server: null,
parser: [HTTPParser],
_httpMessage: [Circular],
[Symbol(asyncId)]: 64,
[Symbol(lastWriteQueueSize)]: 0,
[Symbol(bytesRead)]: 0 },
_header: 'GET / HTTP/1.1\r\nSec-WebSocket-Version: 13\r\nSec-WebSocket-Key: /uaYfhj4eXLwTI4NXc15B2QKJQ==\r\nConnection: Upgrade\r\nUpgrade: websocket\r\nSec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\nHost: redacted:xxx\r\n\r\n',
_onPendingData: [Function: noopPendingOutput],
agent: undefined,
socketPath: undefined,
timeout: undefined,
method: 'GET',
path: '/',
_ended: false,
res: null,
aborted: undefined,
timeoutCb: null,
upgradeOrConnect: false,
parser:
HTTPParser {
'0': [Function: parserOnHeaders],
'1': [Function: parserOnHeadersComplete],
'2': [Function: parserOnBody],
'3': [Function: parserOnMessageComplete],
'4': null,
_headers: [],
_url: '',
_consumed: false,
socket: [Socket],
incoming: null,
outgoing: [Circular],
maxHeaderPairs: 2000,
onIncoming: [Function: parserOnIncomingClient] },
maxHeadersCount: null,
[Symbol(isCorked)]: false,
[Symbol(outHeadersKey)]:
{ 'sec-websocket-version': [Array],
'sec-websocket-key': [Array],
connection: [Array],
upgrade: [Array],
'sec-websocket-extensions': [Array],
host: [Array] } } }
And it stays forever that way. The only thing I see relevant is the _closeCode: 1006 field. Now I'm stuck. What can I do? Shouldn't rpc-websockets handle this error?
Just a reminder: sometimes I do get a successful connection, I just don't understand why the Client doesn't keep trying to reconnect in this case.
@lucaswxp Thank you for reporting the issue. Since you can reproduce this one, are you interested in authoring a PR to possibly fix this?
@mkozjak I have no idea how to debug this further, any suggestion? I got as far as I was could by myself.
+1 I am facing the same issue
@lucaswxp Did you find any root cause or a work around to fix this issue?