provider.destroy will reopen connection

[olee]

Description
When issuing a "destroy" on HocuspocusProvider, the underlying websocket connection will be closed as well, however it will always try to reconnect again.
The faulty code seems to be the onClose event:

hocuspocus/packages/provider/src/HocuspocusProviderWebsocket.ts

Lines 526 to 529 in fa2fb2e

	} else if (this.shouldConnect) {
	// The connection was closed by the server. Let’s just try again.
	this.connect()
	}

When I debugged the code, I noticed that event.reason == 'provider_initiated', so I think the code above there just needs a check for this type of close reason and set shouldConnect to false.

Steps to reproduce the bug
Steps to reproduce the behavior:

1. Create HocuspocusProvider
2. Call HocuspocusProvider.destroy

Expected behavior
Connection is properly closed and not reestablished.

[olee]

I noticed that I need to explicitly set preserveConnection option to false to cause the connection to be closed on destroy.

On that note though, I now instead want to try to preserve the connection and even though preserveConnection is set to true, the connection is closed for a moment each time a HocuspocusProvider is destroyed.

EDIT:
Tracing this a bit more it seems that when destroying a HocuspocusProvider a CloseMessage on the document which is fine.
However, it seems this causes the server to directly close the websocket connection, even though it still might be reused:

hocuspocus/packages/server/src/MessageReceiver.ts

Lines 96 to 102 in fa2fb2e

	case MessageType.CLOSE: {
	connection?.close({
	code: 1000,
	reason: 'provider_initiated',
	})
	break
	}

What is the correct solution when I want to keep my websocket connection alive to use it for multiple HocuspocusProviders?

[chwzr]

Have the same use case here: We are doing multiplexing with one HocuspocusProviderWebsocket and multiple HocuspocusProvider. However when we want to sync to a different document we destroy the HocuspocusProvider and create a new one. This works fine, but this triggers the Websocket to close ( like @olee traced already is done by the server handling the CLOSE message).

In our case we have open an overlay in our application which shows that the HocuspocusProviderWebsocket is not connected. When we change the document this overlay is triggered for 1 second which is annoying.

I think the correct place to fix this is in the CLOSE Message - the client needs to choose whether it wants the server to close the connection or not, depending on other HocuspocusProviders registered to that HocuspocusProviderWebsocket it should not close the connection per default. What do you think?

[tobowers]

Re-iterating that it seems like multi-plexing might not work at all?

[janthurau]

the server will close the connection if no document is open, which causes issues if you want to switch documents by closing and then opening a new one. Maybe we can just add some kind of timeout before the server closes the connection, but as a workaround you should be able to just delay destroy of the provider until after a new provider attached.

[jimfilvo]

hi @janthurau the ideal way for my particular case is that I create HocuspocusProviderWebsocket separately and HocuspocusProvider using the HocuspocusProviderWebsocket that way I can create HocuspocusProviderWebsocket anywhere in my app which stays open either by default or if you don't want to do it then may be with some property. and HocuspocusProvider is running via that websocket and on switching on the document it just destroys the provider and create a new provider, but don't disconnect the HocuspocusProviderWebsocket.

I tried that with existing structure but HocuspocusProviderWebsocket doesn't stay open, it just closes after 30 sec with a message that Invalid Token provided. I really wish if the above structure was in place, that would have solved a lot of multiplexing issues. All companies like notion, slite etc works that way.