So Netlify imposes a 10 second timeout on function calls: Functions overview | Netlify Docs (this is pretty common with the various hosting providers, Vercel limits to 15 seconds). There are a couple of ways around this: switch to their Background Functions (but you’ll need to update your frontend to do polling or something similar to find out when the process is complete), or you can apparently message their support team and they can increase the timeout to 26 seconds (not sure if you have to be on a paid plan or not): Increase function timeout limits - from 10s to maximu (26s) - Support - Netlify Support Forums
For dbAuth: how often do you see a bad auth header? It should be never! You should be either logged in (and sending up a valid header every time) or not logged in (and not sending any auth header at all). There is logic in there that if you tried to tamper with your session cookie, and now it’s un-decryptable, that dbAuth will clear the session cookie, and then whatever logic you have in your client to deal with unauthenticated users should kick in (redirect them to the login page, maybe). If you’re looking at the Network tab of Web Inspector, which request is failing? Is it one to auth?method=getToken or calls to graphql?
@dthyresson - thanks, I’ll look into that retry utility !
@rob - I will try to determine a pattern, the last time I dug into it it was failing to pull something from an undefined context, but I changed my frontend to be a little more stable and the problem went away there.
I still get these occasionally – how would you suggest I include some global catch for these? I would certainly route to the /logout page
Hmm, good question. The error may be occurring in getCurrentUser() in api/src/lib/auth.js. That function should only be called if a user is logged in, so the session argument should always be populated and present. But if the auth header was screwed up somehow, internally maybe isAuthenticated is true, but the session data doesn’t actually exist. So it’s calling that function with null or undefined and then looking up the user is what blows up. Possibly?
Is it possible that you have a state issue somewhere, where you’re assuming currentUser exists, even when it sometimes doesn’t? When a component first renders, currentUser will be null until dbAuth hits the server and returns the correct user ID from session. Then, currentUser will update with the correct data, which will cause a re-render of anything depending on that value. We’ve seen this cause an issue in tests, where if you test the value of currentUser right away, it’s null (even though the user is logged in) and it’s because of having to wait for the server to respond. You need to add waitFor() to your test suite before checking the value of currentUser in a test.
The initial issue was happening when I was calling for some resources (messages to display on screen) right after I had called logOut from the auth package
It was annoying to get authentication errors when I had just logged out – perhaps I should wait on ‘loading’ on the logOut call?
Now it seems to be happening randomly - when I’ve not used the app in a while and the token has expired (I’m guessing, here)
What did you set the expires setting to in api/src/functions/auth.js? The default is 10 years!
Yeah you might want to look at using loading. There’s an example usage in the docs, rendering null until auth has figured out who you are: Docs - Authentication : RedwoodJS Docs
