Arvados » Arvados Workbench 2

The same is true for deleting properties ...
The first time something goes wrong is due to the following error "Failed to load resource: the server responded with a status of 422 (Unprocessable Entity)" in https://wb2.ardev.services.caasnq.emea.roche.com/static/node_modules/axios/lib/adapters/xhr.js line 178
When that happened once the page is not working anymore and need to be reloaded.

I do not really see a pattern when it happens and when it works smoothly. Most of the time only one change works and then it is broken due to the mentioned error ... reloading of the page helps to reset the thing

It seems there is an issue related to the versioning features. The response message of the api is

{errors: ["Version cannot be updated"], error_token: "1553868569+72636ad3"}

This indicates the frontend is updating an older version of the current collection instead of the latest version (old versions are immutable). However the API call is using the same UUID which should always refer to the latest version.

Another indication that this is frontend related is that the issue can be worked around by reloading the page. Maybe this can be fixed by replacing the object in memory by the response of the update api. It could be that the second update is sending outdated fields (e.g. the version number)

Reflecting on the error message it might be that the only issue is that the API is complaining that the workbench is trying to update the "version" field. If this can be removed from the PUT Request Payload I assume it solves the issue.

Moritz Gilsdorf wrote:

Reflecting on the error message it might be that the only issue is that the API is complaining that the workbench is trying to update the "version" field. If this can be removed from the PUT Request Payload I assume it solves the issue.

I agree, the "version" cannot be updated by the client and should not be sent in the PUT request.

One comment on the video, if the API server is returning an error, workbench2 should be reporting that an error occurred and not silently ignoring it (which leads to more confusion).

I will investigate a little bit more and see if I can confirm Moritz's theory.

Yes, I see a more general problem that workbench2 is sending back a number of parameters which are present in the GET response but are not legal for the client to update:

created_at
current_version_uuid
delete_at
etag
href
is_trashed
kind
modified_at
modified_by_client_uuid
modified_by_user_uuid
preserve_version
replication_confirmed
replication_confirmed_at
storage_classes_confirmed
storage_classes_confirmed_at
version

To avoid errors, the PUT should only include the fields the client explicitly intends to update.

Updates at 49f27be (wb2 repo) - branch 15027-object-update-fix

• Reviewed all the update calls to the API server so that only the data being updated is sent and not the entire records.
• Because #15407 is already merged, the collection's tag creation/deletion issues originally reported on this ticket are fixed as the properties (and other similar attributes) aren't being translated to back and forth between camel and snake case. Sometimes, the properties field was being translated to camel case when being received from the API server but not translated back when updated.
• Also fixed a pending typo on the group's writable_by field.

This LGTM. One small nit is that some of the imports are no longer needed in the files you updated. Seems to be a problem in a lot of places, but might as well clean up where we can. Thanks!

Updates at 239ccc4

• Removes unused imports
• Installs & configures tslint to prohibit unused declarations in general
• Fixes pending unused declaration errors.

Removed commented out code at c354d605

Lucas Di Pentima wrote:

Removed commented out code at c354d605

LGTM! Thanks for cleaning it up!