Open eatyourgreens opened 6 days ago
This bug might be caused by requesting a token before auth.checkCurrent()
has resolved. See #6345, which should fix delayed loading for notifications. Delays of ~60s or more would be consistent with waiting for the SWR cache to invalidate and revalidate. I think the default cache lifetime is 60s, but I could be wrong. It might depend on the Cache-Control headers sent with a resource.
So, maybe an API request is made with an empty token (by mistake) and cached, then not refreshed until at least a minute has passed.
With the Panoptes JavaScript Client, it's good practice to make sure that auth.checkCurrent()
has resolved before requesting a token. Otherwise, there's a race condition where you might request a token before sign-in is complete.
await auth.checkCurrent()
const token = await auth.checkBearerToken()
Package
Describe the bug
A couple of volunteers have reported very long load times for components with the new app router:
@yshish
https://www.zooniverse.org/talk/2354/3435274?comment=5662110
@am.zooni
https://www.zooniverse.org/talk/2354/3435274?comment=5661742
To Reproduce
I've not seen this myself, so I'm not sure how to reproduce it. If Sentry is set up for the new React Server Components, it should log slow-running components, so you should be able to find this bug in Sentry.
New Relic will probably have logs too, if HTML streaming is taking ~60s.
Expected behavior
Components that depend on API requests should load data in ~1s or less (probably much less.)
Additional context
Million.js v3.1 includes a performance linter for VS Code, which can log slow-running components and excessive re-renders. I've found that very useful for debugging React performance.