Cannot submit or edit datasets from Chrome version 120.0.6099.71 #2235
Comments
|
Able to reproduce this with |
|
The SFWMD folks reported an issue that they couldn't add two data objects to an existing package. @jeanetteclark reproduced the issue by using the latest Chrome browser while she succeeded to add files by using Firefox. I think this is relevant even though the error message is different. The error shows the new eml object is invalid: The package was originated from Morpho so it has the access part in the eml document, even though now we don't use that part for access control. |
|
The SFWMD folks reported both Chrome and Microsoft Edge had the issue. |
|
Not entirely sure if this is the problem, but sharing some observations. It looks like the sysmeta that we're trying to upload looks jumbled up in Chrome 120.X vs in Chrome 119.X. Here is the file that I was testing this with on test.arcticdata.io Console log of sysmeta from Chrome 120.X: Chrome 119.X Please ignore the I think this is the code block that generates this xml. Not sure why the same code is giving two different results in different versions of the browser. Still testing a few things before I can tell for sure if this is the problem. |
Return serialized XML objects instead of String Reference: #2235
Update AccessRule model to parse garbled XML Reference #2235
|
update: 12/18/2023 refactored the accessRule.serialize() and accessPolicy.serialize() functions to return XML objects instead of XMLString objects (commit). This seems to resolve the parsing issues with jQuery replaceWith that we’ve been experiencing with Chromium 120.X. (The idea is to provide jQuery with structured content instead of letting it parse and form a structure from the given XML string). I’ve added this fix to this branch and deployed it on handy-owl (requires UCSB VPN) for testing. status: able to successfully submit new datasets on Chromium 120.X; still seeing issues with editing update: 12/19/2023 While editing existing datasets, the parsing of the access rule failed due to a garbled XML string (see below), despite the sysmeta response from the <accesspolicy>
<allow>
<subject>http://orcid.org/0000-0001-8888-547X</subject>
<permission></permission>read
<permission></permission>write
<permission></permission>changePermission
</allow>
<allow>
<subject>CN=arctic-data-admins,DC=dataone,DC=org</subject>
<permission></permission>
"read "
<permission></permission>
"write "
<permission></permission>
"changePermission "
</allow>
</accesspolicy>Consequently, the I have added a fix in the above commit to rectify this issue. I conducted tests with a few of Jeanette's datasets on handy-owl pointing at test.arcticdata.io, and it appears that I am now able to edit them successfully and access the new dataset version on MetadataView. status: ready for additional testing at handy-owl (requires UCSB VPN) |
|
Nice work @rushirajnenuji - I just tested editing and submitting from Chrome and it seems to be working for me |
|
Excellent prompt response @rushirajnenuji! Thanks for the fix. |
|
@rushirajnenuji @robyngit @mbjones @artntek We are seeing strange behavior in metacat when reproducing this issue on our deployments. I created a new dataset (in chrome 120.0.6099.109) and tried to add a file and saw the error as described above in the UI. I also saw errors in Metacat (see below). I also tried to save the dataset and received an error: For each PID in the error (see example below):
Looking in Postgres
Sytem meta data records Example of Metacat Issue Metacat Log Errors |
|
@rushirajnenuji I have also noticed that if I am not the rightsHolder but am in the group that is in the access policy, I cannot share a dataset. In the example below, I should have changePermission. 
|
This is for Metacat 2.18.0 |
|
Hi @vchendrix, thanks for the detailed report! Was this error produced when submitting a dataset via the editor using the latest patched version of MetacatUI, or with one of the older versions? |
Hey @robyngit. The error was produced with Metacat 2.23.0. We have yet to deploy the patch release. |
|
Looking in the |
And just to double check, in your tests, you were using the latest version of chrome and submitted a new or updated dataset via the editor? I'm trying to understand if you've found that this problem goes beyond the issue we tracked down and fixed in the latest release, if so, we should reopen this issue. Edit: Thanks to @artntek for filling in some of the details I missed here! I understand now that this was with the latest version of chrome and in the editor, and the unexpected part is that the data files are missing. |
|
@mbjones and I investigated the scenario reported by @vchendrix. In summary:
We therefore believe that you should be able to delete the orphaned |
Ok. this makes sense. Do you think that you can write a clean up script for this? |
To elaborate on this slighty, because the steps are not part of a transaction, we have the systemmetadata record saved, but the xml_access metadata record fails with an exception. The exception generated there prevents the rest of the downstream data objects and access log records from being saved. @taojing2002 @doulikecookiedough in the upcoming metacat 3.0.0 relelase, hazelcast will be gone, but this transaction bug will still be latent in the |
|
actually, on |
DONE: Metacat PR # 1764 |
Describe the bug
All users of the new version of chrome cannot submit datasets. This has been seen on both the ADC and SCTLD.
To Reproduce
Steps to reproduce the behavior:
The error that shows up in the red banner says:
In the console we have:
In catalina.out:
Interestingly, an object actually is submitted, an EML saved as a plain text which is our attempt to help users not lose work on errors. If you try to save again after the first error you'll get a new error saying the pid is already in use.
Desktop (please complete the following information):
Related bug
If instead of submitting a new dataset, you edit a dataset that is not your own, that dataset will have it's access policy removed. The EML is submitted normally otherwise
The catalina.out error here is:
The text was updated successfully, but these errors were encountered: