Open Cluster2a opened 10 months ago
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?
@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.
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?
@FZambia, in production I am using the same version. Okay - that is weired. Not sure what is causing this.
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.
Describe the bug If the websocket connection is blocked a reconnect & close raises en error.
To Reproduce
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