Bug #21925
closed
fetchProcessProgressBarStatus triggering continuously
Added by Peter Amstutz 5 months ago.
Updated 3 months ago.
Release relationship:
Auto
Description
fetchProcessProgressBarStatus triggers hundreds of times, when it is only supposed to trigger periodically.
Example:
https://workbench.tordo.arvadosapi.com/processes/tordo-xvhdp-bd68mbek1to5upj
Open the network debugger, and you'll see hundreds of requests in a short period of time. Once loading is finished and it knows the state of the container, it does seem to stop doing it.
I believe this is affecting Cypress tests for the process panel, by slowing things down and also re-rendering continuously which causes cy.waitForDom() to time out.
Stephen says: "Ah, I added the process resource object to the dependency array of the useeffect triggering reloading the stats so it reloads it every time the resource gets modified during loading"
- Assigned To set to Stephen Smith
- Subject changed from fetchProcessProgressBarStatus triggering continuously to fetchProcessProgressBarStatus triggering continuously
- Description updated (diff)
- Description updated (diff)
- Description updated (diff)
Changes at arvados|88a2b9ecacd512748403fb0d45532dce5c65a64f branch 21925-progress-bar-useeffect-fix
Tests developer-run-tests-services-workbench2: #938 
- All agreed upon points are implemented / addressed.
- Changes progress bar fetch to accept UUID
- Split polling flag into 2 for process and project
- Fetch method now only returns polling flag for projects
- The previous changes for project support switched to updating isRunning in the fetch action where it would use the store for processes and progress counts for projects
- This resulted in polling not starting if a draft process is already open when started since it would only update if already polling
- This new approach uses the store (including WS updates) for processes and polling-based updates for projects
- Splitting these up also allows eliminating an extra refresh when project polling stops while keeping a final refresh when websocket updates a process to stopped
- Added comments and better type guards
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- Code is tested and passing, both automated and manual, what manual testing was done is described
- manually tested by viewing a project's runs tab while all processes stopped, while 1 running to verify polling, and viewing a finished and running process' subprocess panel & verifying that polling starts and stops when a draft process is started & finishes.
- Documentation has been updated.
- Behaves appropriately at the intended scale (describe intended scale).
- Considered backwards and forwards compatibility issues between client and server.
- Follows our coding standards and GUI style guidelines.
- Status changed from New to In Progress
Stephen Smith wrote in #note-5:
Changes at arvados|88a2b9ecacd512748403fb0d45532dce5c65a64f branch 21925-progress-bar-useeffect-fix
Tests developer-run-tests-services-workbench2: #938
- All agreed upon points are implemented / addressed.
- Changes progress bar fetch to accept UUID
- Split polling flag into 2 for process and project
- Fetch method now only returns polling flag for projects
- The previous changes for project support switched to updating isRunning in the fetch action where it would use the store for processes and progress counts for projects
- This resulted in polling not starting if a draft process is already open when started since it would only update if already polling
- This new approach uses the store (including WS updates) for processes and polling-based updates for projects
- Splitting these up also allows eliminating an extra refresh when project polling stops while keeping a final refresh when websocket updates a process to stopped
- Added comments and better type guards
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- Code is tested and passing, both automated and manual, what manual testing was done is described
- manually tested by viewing a project's runs tab while all processes stopped, while 1 running to verify polling, and viewing a finished and running process' subprocess panel & verifying that polling starts and stops when a draft process is started & finishes.
- Documentation has been updated.
- Behaves appropriately at the intended scale (describe intended scale).
- Considered backwards and forwards compatibility issues between client and server.
- Follows our coding standards and GUI style guidelines.
LGTM
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
Updated by 
Updated by