Project

General

Profile

Actions

Bug #15027

closed

[WB2] [Data operations] Error attempting to set read-only attributes

Added by Chrystian Klingenberg about 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Story points:
-
Release relationship:
Auto

Description

During my work on tickets regarding multi-value properties, I've noticed strange behaviour. I am sure it was working properly before, however now on the ardev it's not working at all and on c97qk only sometimes, which is even more strange. It's mostly about rewriting and adding new value.

I attached a recording with an explanation where you can see this issue in both environments.


Files

properties.mp4 (7.98 MB) properties.mp4 Chrystian Klingenberg, 03/27/2019 12:43 PM

Subtasks 1 (0 open1 closed)

Arvados - Task #15549: Review 15027-object-update-fixResolvedLucas Di Pentima08/22/2019Actions
Actions #1

Updated by Chrystian Klingenberg about 5 years ago

Actions #2

Updated by Jan Kuentzer about 5 years ago

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

Actions #3

Updated by Moritz Gilsdorf almost 5 years ago

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)

Actions #4

Updated by Moritz Gilsdorf almost 5 years ago

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.

Actions #5

Updated by Peter Amstutz almost 5 years ago

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.

Actions #6

Updated by Peter Amstutz almost 5 years ago

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.

Actions #7

Updated by Peter Amstutz almost 5 years ago

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.

Actions #8

Updated by Peter Amstutz almost 5 years ago

  • Subject changed from [Data operations] Properties - unknown behaviour to Attempting to set read-only properties
Actions #9

Updated by Peter Amstutz almost 5 years ago

  • Subject changed from Attempting to set read-only properties to Error attempting to set read-only attributes
Actions #10

Updated by Chrystian Klingenberg almost 5 years ago

  • Target version set to Backlog Q1, Q2
Actions #11

Updated by Chrystian Klingenberg almost 5 years ago

  • Subject changed from Error attempting to set read-only attributes to [Data operations]Error attempting to set read-only attributes
Actions #12

Updated by Chrystian Klingenberg almost 5 years ago

  • Subject changed from [Data operations]Error attempting to set read-only attributes to [Data operations] Error attempting to set read-only attributes
Actions #13

Updated by Pawel Kowalczyk almost 5 years ago

  • Status changed from New to In Progress
  • Assigned To set to Pawel Kowalczyk
Actions #14

Updated by Pawel Kowalczyk almost 5 years ago

  • Status changed from In Progress to Resolved
Actions #15

Updated by Chrystian Klingenberg almost 5 years ago

  • Status changed from Resolved to Closed
Actions #16

Updated by Tom Morris almost 5 years ago

  • Status changed from Closed to In Progress
  • Assigned To deleted (Pawel Kowalczyk)
  • Target version changed from Backlog Q1, Q2 to Workbench2 Q3, Q4

We need a more complete fix here so that only attributes which are being updated (and no unmodifiable attributes) are sent with the update.

Actions #17

Updated by Tom Morris over 4 years ago

  • Target version changed from Workbench2 Q3, Q4 to 2019-08-28 Sprint
Actions #18

Updated by Ward Vandewege over 4 years ago

  • Status changed from In Progress to New
Actions #19

Updated by Ward Vandewege over 4 years ago

  • Subject changed from [Data operations] Error attempting to set read-only attributes to [WB2] [Data operations] Error attempting to set read-only attributes
Actions #20

Updated by Lucas Di Pentima over 4 years ago

  • Assigned To set to Lucas Di Pentima
Actions #21

Updated by Lucas Di Pentima over 4 years ago

  • Status changed from New to In Progress
Actions #22

Updated by Lucas Di Pentima over 4 years ago

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.
Actions #23

Updated by Eric Biagiotti over 4 years ago

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!

Actions #24

Updated by Lucas Di Pentima over 4 years ago

Updates at 239ccc4

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

Updated by Lucas Di Pentima over 4 years ago

Removed commented out code at c354d605

Actions #26

Updated by Eric Biagiotti over 4 years ago

Lucas Di Pentima wrote:

Removed commented out code at c354d605

LGTM! Thanks for cleaning it up!

Actions #27

Updated by Anonymous over 4 years ago

  • Status changed from In Progress to Resolved
Actions #28

Updated by Lucas Di Pentima over 4 years ago

  • Release set to 27
Actions

Also available in: Atom PDF