Infinite Load Times and REST API Self Link Mismatches Causing Frontend Sluggishness in DSpace

[aseyedia]

Describe the bug

When using DSpace as a logged-in administrator and particularly when navigating the "Edit Item" tab(s) (or even just clicking "Edit Item"), 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.

Back in August, I submitted issue #3252 (potential duplicate of #2924) which was about the DSpace frontend web browser hanging and crashing when viewing src/app/item-page/versions/item-versions.component.html. @alexandrevryghem implemented a solution in this PR here #3253 and I copied and pasted his changes into my item-versions.component. This solved the "hanging" issue but now I suspect that this fix is potentially playing some role in my current predicament. From the DevTools console, I can tell that numerous REST API request/response mismatches are occurring, particularly related to self links in the API responses:

The response for 'https://pedsdspaceprod.research.chop.edu/server/api/versioning/versionhistories/25/versions?page=0&size=10' has the self link 'https://pedsdspaceprod.research.chop.edu/server/api/versioning/versionhistories/25/versions?page=0&embed=item&embed=eperson&size=10'. These don't match. This could mean there's an issue with the REST endpoint

In addition, I am also gettin this error, though I don't necessarily think it's relevant:

cannot deserialize type systemwidealert
Can't cache incomplete systemwidealert: null, parsed from (partial) response: {"alertId":1,"message":"Please note that PEDSnet is currently under construction.","allowSessions":"all","countdownTo":null,"active":true,"type":"systemwidealert","_links":{"self":{"href":"https://pedsdspaceprod.research.chop.edu/server/api/system/systemwidealerts/1"}}}

Occasional Solr errors too, though these are more sporadic and might also not have to do with this problem.

at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) ~[httpclient-4.5.14.jar!/:4.5.14]
...
at org.dspace.qaevent.service.impl.QAEventServiceImpl.findSource(QAEventServiceImpl.java:528) ~[dspace-api-8.0.jar!/:8.0]
... 209 more

Environment:

DSpace Version: 8.0
Frontend Framework: dspace-angular (specific branch: alexandrevryghem@d09f529)
Solr Version: 8.11.3
Web Browser: Google Chrome 129.0.0.0 on macOS
Additional Context: The issue appears to be related to self-referencing entities and REST API endpoint discrepancies. I have also made a number of changes to the DSpace frontend which are not accounted for here, but nothing pertaining to the API call-and-response. I also am not sure if this is more of a backend or frontend issue and I would be happy to migrate this ticket.

To Reproduce

Steps to reproduce the behavior:

1. Check out d09f529 (again, maybe source of the issue, though I don't know)
2. Try editing items. It might not happen right away; it is occasional. But sometimes it is unrelenting and recurrent.

Expected behavior

The frontend does not hang when "Edit Item" is navigated.

Related work

• d09f529
• Edit Page Hangs on Version History #3252
• Fixed Edit Item's Version History crashing #3253
• Version History causes Item page to hang  #2924
• DSpace API problems in editing items and long load times  DSpace#9879 (backend issue I opened before I had a better understanding of the issue)

[aseyedia]

Actually, now I'm starting to think it has to do more with this Solr exception.

2024-10-10 14:10:22,015 ERROR a4fd2fb0-7be3-4b69-bce3-7d91ef6d3211 be8bc100-a08f-4ade-a3e0-7b30c5900de8 org.dspace.app.rest.exception.DSpaceApiExceptionControllerAdvice @ An exception has occurred (status:500)
java.lang.RuntimeException: Server refused connection at: http://localhost:8983/solr/qaevent
        at org.dspace.qaevent.service.impl.QAEventServiceImpl.findSource(QAEventServiceImpl.java:541) ~[dspace-api-8.0.jar!/:8.0]
...

The Solr core qaevent is accessible and seems to be working fine when I port forward.

[aseyedia]

Moving this to DSpace backend here: DSpace/DSpace#9884