Bug #15027

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

Added by Chrystian Klingenberg 9 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Start date:
08/22/2019
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
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.

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

Subtasks

Arvados - Task #15549: Review 15027-object-update-fixResolvedLucas Di Pentima

Associated revisions

Revision d3b0b860 (diff)
Added by Pawel Kowalczyk 8 months ago

refs #15027-delete-version-attr-on-update-collection

Arvados-DCO-1.1-Signed-off-by: Pawel Kowalczyk <>

Revision 02fe86a5
Added by Lucas Di Pentima 4 months ago

Merge branch '15027-object-update-fix'
Closes #15027

Arvados-DCO-1.1-Signed-off-by: Lucas Di Pentima <>

Revision c6d62c0b (diff)
Added by Lucas Di Pentima 30 days ago

Merge branch '15027-object-update-fix'
Closes #15027

Arvados-DCO-1.1-Signed-off-by: Lucas Di Pentima <>

History

#1 Updated by Chrystian Klingenberg 9 months ago

#2 Updated by Jan Kuentzer 9 months 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

#3 Updated by Moritz Gilsdorf 8 months 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)

#4 Updated by Moritz Gilsdorf 8 months 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.

#5 Updated by Peter Amstutz 8 months 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.

#6 Updated by Peter Amstutz 8 months 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.

#7 Updated by Peter Amstutz 8 months 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.

#8 Updated by Peter Amstutz 8 months ago

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

#9 Updated by Peter Amstutz 8 months ago

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

#10 Updated by Chrystian Klingenberg 8 months ago

  • Target version set to Backlog Q1, Q2

#11 Updated by Chrystian Klingenberg 8 months ago

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

#12 Updated by Chrystian Klingenberg 8 months ago

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

#13 Updated by Pawel Kowalczyk 8 months ago

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

#14 Updated by Pawel Kowalczyk 8 months ago

  • Status changed from In Progress to Resolved

#15 Updated by Chrystian Klingenberg 8 months ago

  • Status changed from Resolved to Closed

#16 Updated by Tom Morris 5 months ago

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

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

#17 Updated by Tom Morris 4 months ago

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

#18 Updated by Ward Vandewege 4 months ago

  • Status changed from In Progress to New

#19 Updated by Ward Vandewege 4 months ago

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

#20 Updated by Lucas Di Pentima 4 months ago

  • Assigned To set to Lucas Di Pentima

#21 Updated by Lucas Di Pentima 4 months ago

  • Status changed from New to In Progress

#22 Updated by Lucas Di Pentima 4 months 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.

#23 Updated by Eric Biagiotti 4 months 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!

#24 Updated by Lucas Di Pentima 4 months ago

Updates at 239ccc4

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

#25 Updated by Lucas Di Pentima 4 months ago

Removed commented out code at c354d605

#26 Updated by Eric Biagiotti 4 months ago

Lucas Di Pentima wrote:

Removed commented out code at c354d605

LGTM! Thanks for cleaning it up!

#27 Updated by Anonymous 4 months ago

  • Status changed from In Progress to Resolved

#28 Updated by Lucas Di Pentima about 2 months ago

  • Release set to 27

Also available in: Atom PDF