You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As for the long loading, despite having really fast internet connection at home, when I click on the new home page, my 'messages' in the top bar shows no new messages although there is 1 unread in my inbox. It takes about 45 seconds before the '1' unread notification loads. (The browser console show no errors.)
Of course, when I load the Talk or visit the old home page through the old-home-page-link I can see the 1 unread there immediately.
Just confirming now that I have seen it happen in 3 further Zooniverse sessions: the message is "there was an error fetching your recent classifications" (in all caps); the bars appear for 60 seconds, then they are replaced by this message briefly, then the bars return. Usually the subject images appear after another 10-30 seconds but sometimes the bars have remained until I gave up and closed the tab. Usually I have left the tab open < 3 minutes but once I waited over 10. (Not waiting because I want to see the subjects; only either to observe what happens regarding the Subject images, or incidental to checking the numbers in the Continue Classifying section.)
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: