Infinite Load Times and REST API Self Link Mismatches Causing Frontend Sluggishness in DSpace
Prologue
This is an x-post from https://github.com/DSpace/dspace-angular/issues/3406; it started with me thinking this was mostly a frontend issue and now I'm not quite sure, because I think the source of the issue is something other than what I had originally thought. I am going to mostly replicate the other issue here but with some additional details that I think will be relevant.
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 https://github.com/DSpace/dspace-angular/pull/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
However, I am also gettin this error, and I am starting suspect it might be the true source of the issue, because I am seeing it appear in the logs more often:
2024-10-10 14:59:15,520 WARN unknown unknown org.dspace.app.rest.security.jwt.JWTTokenHandler @ 10.14.19.125 tried to use an expired or non-valid token
2024-10-10 14:59:15,520 WARN unknown unknown org.dspace.app.rest.security.jwt.JWTTokenHandler @ 10.14.19.125 tried to use an expired or non-valid token
2024-10-10 14:59:15,521 DEBUG unknown unknown org.dspace.core.LegacyPluginServiceImpl @ Adding Sequence plugin for interface= org.dspace.authenticate.AuthenticationMethod, class=org.dspace.authenticate.PasswordAuthentication
2024-10-10 14:59:15,522 INFO a4fd2fb0-7be3-4b69-bce3-7d91ef6d3211 0edef2f3-4378-4270-81b2-d7f5fa7e1544 org.dspace.app.rest.utils.DSpaceAPIRequestLoggingFilter @ Before request [GET /server/api] originated from /entities/person/7463eebb-c2cf-46df-9a4f-cb9c862115c0
2024-10-10 14:59:15,522 WARN unknown unknown org.dspace.app.rest.security.jwt.JWTTokenHandler @ 10.14.19.125 tried to use an expired or non-valid token
Environment:
DSpace Version: 8.0 Frontend Framework: dspace-angular (specific branch: https://github.com/alexandrevryghem/dspace-angular/commit/d09f5297a1f4e36071494bd89dc462b7538b3474) 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:
- 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
- #3252
- https://github.com/DSpace/dspace-angular/pull/3253
- #2924
- https://github.com/DSpace/DSpace/issues/9879 (backend issue I opened before I had a better understanding of the issue)
This issue is potentially duplicates with https://github.com/DSpace/DSpace/issues/8577?
I actually don't think it's duplicates with the problem above. Not really sure what the source of the issue is but I can't dedicate any more time to it. Does anyone else have this problem? Logged-in admins experiencing intermittent infinite load times and having to refresh the browser page a bunch?
@aseyedia : As of today, I've not seen this issue reported by anyone else (e.g. on mailing lists, Slack or in GitHub). We are also not seeing this behavior on our Demo site (running 8.0) at https://demo.dspace.org
So, that makes me immediately suspect that either you have something different in your installation, or your "data" is in some way unique. It's really impossible for me to guess at though, because I cannot reproduce this issue anywhere.
My only suggestions are to see if any of this helps:
- See if you can reproduce this bug on demo.dspace.org. If so, then it's definitely a DSpace bug, and please report the steps you took to reproduce it.
- If not, try out the Troubleshooting Guide to see if you can find an error message occurring at the point where you reproduce the bug. The error could be in either the browser (use DevTools) or maybe on the backend (check the logs), or maybe both.
Regarding what you shared so far, everything you shared above from your logs is a WARN and not an ERROR. "WARN" messages do NOT always imply a bug or issue, so they may be false positives. You want to be looking for ERROR messages in log files.
For instance while #8577 is annoying (as it may appear in the logs quite a bit), these "self link" mismatch messages are NOT severe bugs, and (as far as I'm aware) do NOT impact performance. These messages are indications of minor differences between the link sent to the REST API and the "self link" returned (usually caused by the REST API simply failing to return a passed parameter back in response). They are just a sign that the REST API code may need minor cleanup, but it should not impact performance. (I can also confirm the demo site has these "self link" mismatches in the logs, and they have no impact there.)
@tdonohue Thanks for getting back to me. I guess, depending on one's outlook, this could be good news, because if it's something I did to cause this to happen, then I can also do something to reverse it. We are observing this problem on both of the two DSpace instances I'm developing so clearly it's some "feature" or "customization" that I added in. I'll come back with more details and if I figure out what it was, I'll let everyone know so that they can steer clear of doing what I did.
I'm going to close this as incomplete and open a new issue with a more precise description and steps to reproduce.