Uncaught TypeError: this._transport.close is not a function

[Cluster2a]

Describe the bug
If the websocket connection is blocked a reconnect & close raises en error.

To Reproduce

1. block websockets using https://stackoverflow.com/questions/30912854/is-it-possible-to-temporarily-disable-a-websockets-connection-in-a-local-server (TamperMonkey extension via Chrome)
2. run the connect()
3. wait a few seconds
4. exception raises:
   

As you can see the _startReconnecting() is being executed and later the close().

Expected behavior
If websockets is blocked, there should not be an exception

Screenshots
If applicable, add screenshots to help explain your problem.

Versions

• OS: Ubuntu 23.10
• Browser or environment with version: Version 120.0.6099.216
• Centrifuge client version: 5.0.1

[FZambia]

Hello @Cluster2a

You are using custom script which modifies WebSocket object breaking WebSocket API provided by browser. So that when centrifuge-js tries to close the transport (upon connect timeout firing) – it calls non-existing close method.

Is the only problem you have is this one, when using this custom script for TamperMonkey?

[Cluster2a]

@FZambia, I see this error message from time to time in our sentry log and I could't figure out, what is causing this (mainly mac users). I doubt they are using this kind of script to block the websocket connection, but I am not 100% sure.

[FZambia]

I looked through the code base. If we assume that there are no scripts like above – such error may happen when transport is created (like new WebsocketTransport), then transport.close is called before the transport was initialized (with transport.initialize). I don't see a straightforward path for such thing - centrifuge-js always initializes transport right after constructing it.

Do you have 5.0.1 in production too?

[Cluster2a]

@FZambia, in production I am using the same version. Okay - that is weired. Not sure what is causing this.

[FZambia]

Probably there is a path in the code I am missing, and some browser specifics may also have role here. Will try to look again and think whether there are some non-obvious scenarios. Could you gather more information about this: only Mac + Safari or Chrome also? Does it affect user ability to connect to your service or just happens occasionally? Getting debug logs would be nice also - but I realize this may be hard to get.