Infinite Load Times When Editing an Item or Browsing DSpace

[aseyedia]

Describe the bug

This is a bug I have been struggling with for a long time before I realized I could replicate it on the demo site. Here it is.

Screen.Recording.2024-10-28.at.10.20.43.AM.mov

When browsing DSpace Angular as a logged-in administrator and particularly when navigating the "Edit Item" tab(s) (or even just clicking "Edit Item" once), we experience persistent issues with infinite load times and sluggishness in the DSpace frontend. Often this will require the user (admin) to refresh more than once to get the frontend to work, and this issue adds a considerable amount of time to the use of DSpace.

Sometimes, what I believe to be the same underlying issue will produce the "Error Loading Communities" error when navigating the homepage.

There's an idiosyncrasy with this bug: It will not (or will rarely) reproduce when Chrome DevTools is open. It doesn't matter if you pop the window out, or don't have the Network tab open. It just won't happen (as often). This makes debugging incredibly difficult because you can't even see what is being printed in the console. Regardless, I have taken the time to fix some of the issues showing up in the console (e.g. messages having to do with ePerson misconfiguration), and disabling some of the customizations we've made to our site, still to no avail. This also made it difficult to detect the issue with Angular DevTools. I couldn't find anything in the backend log either, even after tinkering with the log4j configuration.

Something else that makes this issue difficult to diagnose is that it tends to occur more frequently and is more severe on a production instance than a development instance of DSpace. For example, whereas I may only run into this issue once after refreshing, on the production instance, I will run into this issue and have to keep refreshing multiple times. Angular DevTools, which I have attempted to use to understand this issue better, does not work on a production instance, only development instances.

Environment

Like I said, this issue is reproducible on the demo site, but I'm including some potentially important information about our environment down below:

• DSpace Version: 8.0
• Web Browser: Google Chrome 129.0.0.0
• User Operating System: macOS Sonoma 14.7

To Reproduce

Steps to reproduce the behavior:

1. Do not open Chrome DevTools.
2. Log in as admin.
3. Click on any item.
4. Click on 'Edit this Item.'
5. If you haven't encountered the error yet, click around on the tabs until you eventually run into the infinite loading issue.

Expected behavior

I don't mind an occasional hiccup, but this bug is so persistent on our production instance that it's unrelenting and makes actually using DSpace incredibly cumbersome. Our admin has to repeatedly refresh the page in order to get it to work, and according to her, something that should only take 30 seconds will take 10 minutes.

So the expected behavior is the occasional hiccup and not the complete inability to consistently use the app.

Related work

I have made a couple of issues before I knew this was reproducible on the demo site, so not all of them contain strictly relevant information, but I have listed them below, as well as any PRs or other issues that I think might be of importance:

• Infinite Load Times and REST API Self Link Mismatches Causing Frontend Sluggishness in DSpace  DSpace#9884
• DSpace API problems in editing items and long load times  DSpace#9879
• Edit Page Hangs on Version History #3252
• Fixed Edit Item's Version History crashing #3253
• Version History causes Item page to hang  #2924

[tdonohue]

Thanks @aseyedia for the additional details!

I've finally reproduced it on https://demo.dspace.org using Chrome on Windows, and can confirm it only occurs when Chrome DevTools is NOT open. I reproduced it the same way that you did, by editing an Item & clicking on various tabs in the "Edit Item" page quickly in succession.

That said, I've noticed a small pattern. For me, the "hanging" behavior seems to always happen on the tab you click on immediately after clicking on the Bitstreams tab. So, if you click to "Bitstreams" immediately, then the next tab hangs. If you avoid clicking on "Bitstreams" then the hanging will not occur for a while (but I've still seen it pop up eventually).

I've also noticed that, if I open Chrome Dev Tools, and click on the "Bitstreams" tab, I see an EmptyError error in the Chrome DevTools Console that says:

Error {stack: 'Error\n    at https://demo.dspace.org/main.5c6b955e…mo.dspace.org/main.5c6b955e5daf2530.js:1:1882402)', name: 'EmptyError', message: 'no elements in sequence'}

This error seems to occur when the "Bitstreams" tab has no bitstreams listed. In other words, the Item has no Bitstreams.

I don't believe this is the actual bug in all scenarios, but it seems to be an example of one scenario where the page "hangs" indefinitely (because an error occurred in the DevTools). This implies to me that the DSpace UI is not handling or recovering from errors properly -- as I think the UI is getting "stuck" on the loading image when an error occurs. In other words, the UI is not overwhelmed or waiting on a response, but has gotten stuck on the loading image.

That said, it's still very odd to me that, when DevTools is open, the "hanging" never occurs.

Needs a volunteer to investigate further. Flagging a "high priority" as this definitely seems like a bug that can be very annoying. The only "workaround" appears to be to reload the page in the browser.

[kshepherd]

A note that I've encountered this in 7.6 and 8.x as well, additionally when switching from simple to full item view. Most of my DSpace activity is in local, dev-mode instances. I have not managed to find any patterns yet but I'll keep the error @tdonohue noted in mind when I'm next looking

[aseyedia]

Here's a video of this issue happening right off the bat on the demo site.

Screen.Recording.2024-10-29.at.10.45.53.AM.mov

It's not in the video, but all I did was log into the demo site as the admin and click on the first available item on the home page.