An authentication token is required, but you didn’t send one - but token was actually included

[kongweiying2]

Description
Despite following the documentation about how to generate a JWT and set up the TipTapCollabProvider here precisely, the connection to the Cloud Collab service fails. It appears that a token is actually provided, contrary to the warning message.

Steps to reproduce the bug
Steps to reproduce the behaviour:

1. Go to this live deployment: https://lifemap-lfp0bl7vc-eusaybia.vercel.app/q/000000
2. Wait for about 10 seconds, open the console, observe the error:
   [HocuspocusProvider] An authentication token is required, but you didn’t send one. Try adding atoken to your HocuspocusProvider configuration. Won’t try again.
3. Also in the console logs, filter by the string "jwt generated" to see the generated jwt, returned from a cloud function. This jwt is given to the TiptapCollabProvider initialisation.
4. Refer to the files: QuantaStore.tsx for the TiptapCollabProvider initialisation, and index.ts for the cloud function that creates a JWT token from the app secret in the TipTap Cloud dashboard. You can sign in to GitHub when requested to get access to these files.
5. Look at the Network tab in the developer console and refer to the request for wss://dy9wzo9x.collab.tiptap.cloud/
   The token does appear to be sent, despite the console message indicating that no token was sent:
   

Expected behavior
I expect my documents to successfully connect to TipTap Cloud and sync successfully.

Environment?

• operating system: Irrelevant
• browser: Irrelevant
• mobile/desktop: Irrelevant
• Hocuspocus version: 2.11.3

Additional context
We had a lengthy discussion about this in the past in this Discord thread. I've resolved the race condition by using useEffect and reacting to the jwt state variable changing, but this doesn't resolve the issue.

https://discord.com/channels/818568566479257641/1141836806774599781/1145940143618936882

You can ignore the dummy data provided to the provider initially and the errors this causes. The presence of this shouldn't really be causing this main issue.

Thanks in advance for your great work with TipTap!

[r614]

running into the same issue where the warning is unnecessarily emitted. in our case the token is just a hardcoded string that never changes.

const newProvider = new HocuspocusProvider({
      url: "wss://<url>/collaboration",
      name: docName,
      token: "sometoken",
      connect: true,
});

[kongweiying2]

running into the same issue where the warning is unnecessarily emitted. in our case the token is just a hardcoded string that never changes.

const newProvider = new HocuspocusProvider({
      url: "wss://<url>/collaboration",
      name: docName,
      token: "sometoken",
      connect: true,
});

Are you saying that you're able to successfully connect, but the warning is still emitted?

[r614]

yup, connection is successful but warning is still emitted

[Ramnath-Karthikesan]

yes, I'm running into the same problem as well

[maitre-piccolo]

For what is worth, I had this same warning message happening sometimes and it confused me. In my case, it was because the WebSocket provider (HocuspocusProviderWebsocket) was disconnected (due to nginx timeout) when trying to create the main provider connection (HocuspocusProvider) with it as parameter (websocketProvider).

Instead of telling that the WebSocket provider (HocuspocusProviderWebsocket) was simply disconnected, it threw this warning.

So it seems this warning message is triggered for the wrong reasons in some cases.

[Twelve-Jiang]

after I destroy the provide, about 5 seconds, it will be emited. It caused by disconnect? or destory? how can i avoid it?

[OdinVerst]

I encountered a similar issue.

const token = JSON.stringify({
    personId: personId,
});

const websocketProvider = new HocuspocusProviderWebsocket({
    url: 'url',
    WebSocketPolyfill: WebSocket,
});

provider = new HocuspocusProvider({
    websocketProvider,
    name: request.EntityId!,
    token,
    document,
    broadcast: false,
});

[fuadsaud]

This warning is emitted when the websocket connection closes with an "unauthorized" reason.

But it seems that the hocuspocus server uses it to close in cases which are not related to authorization at all:

• idle connection
• decoding failure
• close error
• close error 2

This seems semantically incorrect to me. But more importantly, if I understand correctly, the provider will not reconnect in those cases. I'm investigating some cases in which our providers won't reconnect to the server after the websocket connection closes for some reason and I suspect this might be related.

[dpnova]

To second what @fuadsaud said - the message is sent in a bunch of irrelevant instances, they are plain to see in the source code.

I'm wagering that hocuspocus is getting less attention now that tiptap has a commercial offering