Replacement of files resulted in no resource map being created for dataset

[justinkadi]

Describe the bug
A submitter replaced 2 files in a dataset, and this resulted in an updated dataset (metadata PID: urn:uuid:8f77980d-f6e9-4bd0-b022-086b54d3ebe8) with no resource map. I checked with my admin token to see if there was a resource map that just hadn't been indexed, but didn't see one. I ended up creating one for the metadata PID with the data files from a previous resource map. I checked SOLR to see if the 2 files were indexed, and they were indexed, but there was no resource map attached to them.

• urn:uuid:3687a579-38db-45bc-ae1c-258a38cf18cc (IVO_meteo_2022_2025.csv supposed to replace IVO_meteo_2022_2024.csv)
• urn:uuid:54def03c-e8b0-4f1a-a49e-295f30eb61aa (ATQ_meteo_simplified_2024_2025.csv supposed to replace ATQ_meteo_simplified_2024.csv)

Additional context
I have not tried replacing the files again yet, as I'm not sure if it'll error again.

[robyngit]

Difficult to deduce why the resource map was not created. Searched Solr for all submissions by the submitter to see if there was perhaps a malformed resource map created. Could not find anything. This dataset has a SID, which shouldn't matter, but might be worth walking through the save process for datasets with seriesIds to see if anything unexpected could be going on.

This issue sounds similar to #2543, implying that it was perhaps not fixed? However, from the RT ticket, it doesn't appear the author encountered any errors as would be expected with #2543.

Otherwise, the issue could be an instance of #2167, #2134, and/or #1386.

It would be easier for the author or datateam to fix this issue when it arises if we implemented #578.

[robyngit]

Additional notes after reproducing with Justin:

• At first there was a red error banner, but it then switched to
  "Your changes have been submitted." Despite that, two files still showed inline errors: "The previous identifier has already been made obsolete by...".
• From the Network tab we confirmed the PUT requests for those files returned the "already obsoleted by" error.
• Interestingly, the save still completed overall. The dataset persisted and a new resource map was created. That makes this different from the earlier bug fixed in the last release (where edits to a just-created dataset failed until the user navigated away).

Part of the current problem is that partial save failures (on data file updates) are not blocking the overall save. The editor reports success, but with file upload failures. Giving the user a chance to recover from this error before proceeding with saving the EML & RM might be better.

More importantly, we need to figure out what's causing the "PID already obsoleted by" error. Does the Editor try to upload the replaced files more than once? Or is it caused by a previous save attempt, where some files were successfully uploaded, but the EML, RM, etc. failed?

[robyngit]

Related to: #2014