Split processes overview page into sections

[artlowel]

References

First step of the plan detailed here
It builds on #2480

Description

This PR splits the process overview page up into separate sections for running, scheduled completed and failed. These lists update automatically

Instructions for Reviewers

Verify that the process overview page still works, that it updates automatically and that all processes are in the correct sections.

Since this builds on #2480, you can find the differences specific to this PR here

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using yarn lint
• My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[AAwouters]

I processed the feedback.

I'm not sure we should display the "Running" and "Scheduled" sections if there are zero processes in them

When a specific table contains no processes when the page is first opened, it now is collapsed by default.
This saves a bit of space while still showing the user that 'Running' and 'Scheduled' processes are also displayed on the overview page if there are any. If you think it still takes too much space I could decrease the header sizes or look for a different solution.

Or, maybe there's some way to highlight recently finished processes under "Completed" and "Failed"

Implementing a good solution to highlight processes that recently appeared in a table turned out to be a bit more difficult than initially anticipated so we took a different route here:
When creating a new process the ID of the newly created process is included when redirecting the user to the overview page. This ID is then used to highlight the row of that specific process.
Considering most users are mostly concerned with processes they (just) started I think this solves the biggest issue with users not knowing where their process ended up.

[AndreaBarbasso]

I've tested the functionality (with the newest changes) but I've encountered an issue.

If, with devtools open, you keep the tab running for a few minutes (on my laptop this issue occurs after 4 minutes), Chrome stops the page with the following warning:

I think there might be an issue on handling subscriptions, and it might also be found on #2480.

To reproduce the issue, just keep the /processes page open long enough for devtools to set up a breakpoint right before an out-of-memory crash.

Attaching the .har and .heaptimeline files (the first one shows all calls until the crash, the second one records the heap for a full minute only).

out-of-memory-polling.zip

[github-actions]

Hi @artlowel,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[artlowel]

Good catch @AndreaBarbasso

I'm able to reproduce the issue. We're working on a fix

[artlowel]

@AndreaBarbasso It should be fixed now

[tdonohue]

@artlowel and @AAwouters : I'm no longer able to get this to work properly. I'm running this with DSpace/DSpace#9241 as a backend & running in production mode: yarn build:prod; yarn serve:ssr

Now, when I go to the processes overview page I see this. The "Running" and "Scheduled" processes never complete...the "Loading..." message stays at all times.

In DevTools, I see the calls to access those processes both returned a 400 BAD REQUEST error. Here's the two calls that return 400

GET http://localhost:8080/server/api/system/processes/search/byProperty?page=0&size=5&sort=creationTime,DESC&processStatus=RUNNING
GET http://localhost:8080/server/api/system/processes/search/byProperty?page=0&size=5&sort=creationTime,DESC&processStatus=SCHEDULED

Additionally, with Chrome DevTools open on the "Network" tab, I see that every few seconds the same two REST API requests occur over and over again. In just 5 minutes, this page has send 150 requests to the REST API. Here's what the requests look like:

GET http://localhost:8080/server/api/system/processes/search/byProperty?page=0&size=5&sort=endTime,DESC&processStatus=FAILED
GET http://localhost:8080/server/api/system/processes/search/byProperty?page=0&size=5&sort=endTime,DESC&processStatus=COMPLETED

If I reload the page in the browser (triggering SSR), these two calls just start again every few seconds.

Am I somehow missing something? Does this require a different backend PR or is it now broken?

[AAwouters]

@tdonohue
The 'Running' and 'Scheduled' processes use 'creationTime' in the last column. I believe the calls failed because, at the time, DSpace/DSpace#9241 did not contain the 'creationTime' property on processes yet.
I see Alexandre merged main into DSpace/DSpace#9241 at around the same time you were reviewing this feature so I think this is simply an issue of unfortunate timing.

Each table re-requests its content every 5 seconds to have the latest status of the processes. As each table could have different pagination settings, and they request the processes based on their status, these calls are not easily combined.
Considering 4 requests are sent every 5 seconds the expected number of calls in 5 minutes would be 240.
If you think this is too many the request rate can be configured easily.

[tdonohue]

@AAwouters or @artlowel : Could you rebase this quickly? I just merged #2480 and it caused some minor conflicts.

[github-actions]

Hi @artlowel,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[AAwouters]

@tdonohue
Conflicts have been resolved.

[tdonohue]

👍 Thanks @AAwouters and @artlowel . This looks good to me now. Everything appears to work.

A thought for the future... I am slightly concerned that this does 4 requests every 5 seconds. That could cause performance issues on the backend if several people are watching this page at once. E.g. 10 people on this page simultaneously means the frontend will send 40 requests to the backend every 5 seconds.

In other words, we may need to consider looking for a way to decrease the number of requests here if this page gets more usage -- otherwise it could start to bog down the backend. I don't have any great ideas right now, but wanted to point this out as something to consider in any follow-up work.

(We could minimally consider making the 5 second polling configurable in case it gets to be "too much" for some sites. But, I'm going to merge this as-is and consider that a follow-up bug fix if we decide it's worthwhile.)