Bug #21925
closed
fetchProcessProgressBarStatus triggering continuously
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"
Updated by Peter Amstutz 6 months ago
- Assigned To set to Stephen Smith
- Subject changed from fetchProcessProgressBarStatus triggering continuously to fetchProcessProgressBarStatus triggering continuously
Updated by Stephen Smith 6 months ago
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.
- none
- 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.
- n/a
- Behaves appropriately at the intended scale (describe intended scale).
- no change to scale
- Considered backwards and forwards compatibility issues between client and server.
- no impact
- Follows our coding standards and GUI style guidelines.
- done
Updated by Peter Amstutz 6 months ago
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.
- none
- 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.
- n/a
- Behaves appropriately at the intended scale (describe intended scale).
- no change to scale
- Considered backwards and forwards compatibility issues between client and server.
- no impact
- Follows our coding standards and GUI style guidelines.
- done
LGTM
Updated by Stephen Smith 6 months ago
- Status changed from In Progress to Resolved