NCEAS
"The previous identifier was already made obsolete by.." editor save error
It seems like there are some cases where the editor is attempting to update an older version of a package. The user who experienced this error says this seems to occur when:
- looking at changes to her submission by using the back button
- navigating to the dataset through her profile instead of using the pop up window that gives you the option of looking at your data after you save it. So she is avoiding those two things and having fewer issues filling out the metadata.
It sounds to me like the package is being updated when the newer version hasn't been indexed yet. This should be avoidable because we can tell a metadata doc is obsoleted when we get the system metadata.
We should also build in a way to handle these errors when they are received from Metacat. We could either:
- Obsolete the newest version wholesale with the version being saved in the editor, or
- Attempt some kind of merge of the newest versions with the version being saved in the editor, or
- Attempt a merge, abort the save, and show a message that the dataset has been obsoleted already, and ask the user to verify the merge before trying to save again.
We recently encountered this issue on ESS-DIVE (EDSUPPORT-1534). Do you have a recommended work around to avoiding this issue for now that we can tell our users? The particular user who reported this to us will be working on a number of data packages in the next month or two so we want to help reduce the occurrence of this save error. I'm looping in @vchendrix to provide any technical details.
See the quoted message below for a detailed account of their experience with this issue (we resolved the resource map issue for now).
I was able to edit and save this record without much problem. Although I tried to enter a start/end date of YYYY-MM and I got red text complaining about my entry but I was able to save the record no problem but the dates were not included. I suspected I would have received an error message at saving.
I didn’t have success editing and saving this record:
The first error I received was this: “There was a Javascript error during the serialization process: TypeError: metadataInPackage[i].get is not a function” so I tried to remove text where I thought there might be issues. Turns out the record was saved even with the error message.
I then tried to edit the record again and save and got this message : “The previous identifier has already been made obsolete by: ess-dive-111b164300c4b17-20210901T202058087” So I don’t’ know what that means or what any of the errors mean.
@mburrus Thank you for the details. From the details in your quoted text, it sounds like your user has encountered an undiscovered bug related to the dates and serialization. I'll create a new Github issue for that.
In general, there's no great way to avoid the The previous identifier has already been made obsolete by... error except for ensuring the metadata has been indexed before editing it by accessing the editor from the dataset landing page (/view/..) and refreshing the page before editing to ensure the latest version has been grabbed. But we should improve this functionality so that those steps don't need to be taken.
Thanks Lauren, I'll keep this in mind and convey this recommendation to our user base if they encounter it.
I encountered this bug again today when I went into the Editor and only updated the file name. Steps:
Click Edit from MetadataView Click into filename input in the DataItemView Type to change the filename Click Submit
The EML and Data file are saved successfully. The resource map is not bceause the editor tries to save with the same id instead of creating a new one. Related to #2020
Same problem documented in #2590:
Steps to reproduce
- Make a new dataset with at least one file
- Save the dataset
- Edit the dataset and change the file name, don't change ANYTHING else
- Save the dataset
- See error:
HashStore refs files already exist for pid resource_map_urn:uuid:... and cid: 8ed23f53022a...
If you change anything in the EML at the same time that you change the file name, the error does not occur. This is odd because the EML does change when a file is renamed in the <entityName> element.
