loading participant list on study tab is slow (or times out)

[BmBaczkowski]

This relates to the "Participant" tab when on Study. Loading the list of participants can be very slow, and sometimes may even be timed out. Similar issue with loading time appears on the dialog box evoked by jobs reset.

[smathot]

I don't see this myself, even though the test system is seeded with quite a bit of dummy data. Do you experience this yourself, or only saw it on the system of @nclaidiere ?

[BmBaczkowski]

I saw it mainly on the system of @nclaidiere but when looking at the Network on my own machine, there is indeed request (Jobs) that takes more time than others (sec vs msec), as it indexes the whole DB instead of only those participants that are allocated in the respective study -- this is my understanding of the root cause.

[smathot]

Okay. Can you point me in the right direction? I.e. to which points in the code/ which queries did you trace down the issue. I've re-assigned the issue to myself – it falls outside of the scope of the current package.

[BmBaczkowski]

I identified the following potential issues:

1. Opening a Study/Participants view triggers broad data processing

• opening a Study to inspect its participants triggers a jobs request, even though the Jobs tab may never be opened. This is here
• The UI loads only a page of participants, but then asks for queue positions with no participant restriction. For example, here it does not tell the queue endpoint which participants it actually needs. And here, there is no participant filter in the request. This is then followed here. Perhaps the most important is the SQL query itself, which queries broader dataset than UI needs.

2. Opening the reset-jobs dialog loads much more participant/job data than the dialog needs

• clicking the reset-jobs button first calls the general participant-jobs endpoint; then the dialog box opens. The application therefore performs relatively expensive database queries and serialization, transfers a larger response to the browser, and then discards most of that information by filtering the result client-side to: status_id === 3

3. Resetting selected jobs actually resets a continuous range of jobs (bug)

• the semantics of the UI and the reset operation do not match. The UI presents a set of individually selectable jobs, but the backend receives only a continuous range.

[BmBaczkowski]

Issue 2 is now in #260 and issue 3 is now in #259