Describe the bug
If you attempt to roll back a data set which has a blocking record, then refresh the page before clicking the "Stop" button in the dialog with the error, you are permanently locked out from attempting this action again due to the uploaderstatus caching the state.
To Reproduce
Steps to reproduce the behavior:
-
Create a new record in a WorkBench upload
-
Create a new record in data entry (or WorkBench) and link it to that record (e.g. a new agent in a new CO)
-
Attempt to rollback the new upload and notice that there is an error shown
{
"uploaderstatus": {
"operation": "unuploading",
"taskid": "5e770147-5027-43e5-80e9-08e83e0b22c5"
},
"taskstatus": "FAILURE",
"taskinfo": "RollbackFailure('Unable to roll back Agent object (2571) because it is now referenced by another record.')"
}
-
Close the tab without clicking on the "Stop" button in the error dialog
-
Navigate back to the WorkBench data set
-
Click Roll Back and confirm the roll back initiation
-
See that it returns you to the data set without any warnings in the UI
-
Check the 'network' logs, or the console, and see the error:
{
"type": "invalidResponseCode",
"statusText": [
"Invalid response code 409.",
"\n This error happened because the resource you tried to update has already\n been modified by someone else. Please refresh the page and try again.\n ",
"Response:"
],
"responseText": "dataset in use by uploader."
}
This leaves the user in a position where they cannot roll back the data set even if they removed the link. To proceed, they need to clear the uploaderstatus value for that record in the spdataset table manually, which cannot be done using the UI. Here's an example of what gets stuck in the uploaderstatus column:
{"operation": "unuploading", "taskid": "bb5bf16c-1293-4c60-b347-29ad76af2076"}
Expected behavior
If the dataset in use by uploader. message is being received, the user should see it in the UI. The user should have the ability to stop the process and have it function just like it was cancelled rather than making the option completely inaccessible if they did not click the "Stop" button before the tab closed.
Screenshots
If applicable, add screenshots to help explain your problem.
Crash Report
Occurrs on v7.12.0.6 and main (7fc918f).
Arc browser, macOS, recreated on https://sp7demofish.specifycloud.org/
Describe the bug
If you attempt to roll back a data set which has a blocking record, then refresh the page before clicking the "Stop" button in the dialog with the error, you are permanently locked out from attempting this action again due to the
uploaderstatuscaching the state.To Reproduce
Steps to reproduce the behavior:
Create a new record in a WorkBench upload
Create a new record in data entry (or WorkBench) and link it to that record (e.g. a new agent in a new CO)
Attempt to rollback the new upload and notice that there is an error shown
{ "uploaderstatus": { "operation": "unuploading", "taskid": "5e770147-5027-43e5-80e9-08e83e0b22c5" }, "taskstatus": "FAILURE", "taskinfo": "RollbackFailure('Unable to roll back Agent object (2571) because it is now referenced by another record.')" }Close the tab without clicking on the "Stop" button in the error dialog
Navigate back to the WorkBench data set
Click Roll Back and confirm the roll back initiation
See that it returns you to the data set without any warnings in the UI
Check the 'network' logs, or the console, and see the error:
This leaves the user in a position where they cannot roll back the data set even if they removed the link. To proceed, they need to clear the
uploaderstatusvalue for that record in thespdatasettable manually, which cannot be done using the UI. Here's an example of what gets stuck in theuploaderstatuscolumn:Expected behavior
If the
dataset in use by uploader.message is being received, the user should see it in the UI. The user should have the ability to stop the process and have it function just like it was cancelled rather than making the option completely inaccessible if they did not click the "Stop" button before the tab closed.Screenshots
If applicable, add screenshots to help explain your problem.
Crash Report
Occurrs on
v7.12.0.6andmain(7fc918f).Arc browser, macOS, recreated on https://sp7demofish.specifycloud.org/