"Failed to authenticate: \"Token expired\", check your server auth config" using Clerk
I'm running into the above error for my users leveraging the recommended authentication approach with Clerk. Any ideas?
10 Replies
In what circumstances do customers see this? Do you know how long your Clerk tokens are good for? They default to 1 minute but we recommend an hour.
It's definitely when the users tab is sitting for awhile. Let me check. Maybe I need a better way to gracefully handle this
Also curious where this shows up, if there's more state we can expose to help you show a different UI here let us know.
Hey @Chad Maycumber are you using our Clerk integration, as described in docs, and are you on the latest version of Convex? Which version of Clerk are you using?
@clerk/nextjs@npm:4.21.10. convex@npm:0.19.1.
@Michal Srb Yeah I am. Clerk session token is also set to 1 year for me, but I guess that's probably different than the auth token length?
@ballingt You're right about the token length. I will go ahead and try to bump that as well
On this note. Is there something right now where I can maybe catch and check the convex error that get's thrown? Maybe I can try to check for a message in my error boundary
@Chad Maycumber this error should just be a console log, and result in the client being unauthed. So there should be no error, but the user should not be no longer authenticated (depending on frontend code, should show different UI) https://github.com/get-convex/convex-js/blob/541ca6507a5d62b38f46de967db220b0edabebaf/src/browser/sync/authentication_manager.ts#L203-L205
What's the behavior you're observing?
Yeah so what's happening for me is the I have a middleware that checks if the users authed and it throws an error if they hit a route that requires authentication. Because convex throws an error on the frontend they hit my error boundary
gotcha, that makes sense. While the client tries to refresh the token it does not send mutations, but once it fails it lets them through and they are unauthed.
Gotcha same for queries?
Yes, what's supposed to happen is
1. the client receives an auth expired error from the server from either a mutation or a query, which means normal token refreshing must have failed somehow
2. the client stops sending mutations and new queries while it attempts to refresh auth
3. once this last-chance refresh succeeds or fails, unpause and let mutations go again
Could you set the verbose option https://docs.convex.dev/api/interfaces/browser.ClientOptions#verbose so we can see more details of these flows? Are you able to recreate this yourself, or just see it when customers report it?