In DSA, these items are at version 2, but preservation already has a version 2. In reality, these druids should be at version 3. This is why the error reads:
Error: sdr-ingest-transfer : problem with sdr-ingest-transfer (BackgroundJob: 33885904): {:errors=>[{:title=>"Preservation error", :detail=>"Version mismatch in /dor/workspace/fx/925/dk/0468/fx925dk0468/metadata/versionMetadata.xml, expected 3, found 2"}]}
I think we can fix the error by doing the following:
Update the druids so that they are version 3. I think that must be do-able in DSA.
When updating the druids, use "reaccession" as the version description. That means both versions 2 and 3 will have the description "reaccession".
Update the workflow service data so that it is operating on version 3.
Updating the workflow data might not be straightforward. The problem is that the previously existing workflow data from the original version 2 has mostly been overwritten by the current attempt to accession the item. You can see this in the current lifecycles for these objects:
2 reaccession
Opened 2023-08-09 21:28:35 UTC
Submitted 2024-07-02 21:32:26 UTC
Published 2024-07-02 21:32:37 UTC
Deposited pending
Accessioned pending
The "Opened" date is the original date that version 2 was created: 2023-08-09. The remaining dates are from the current attempt at accessioning. That means we need to:
add version 3 workflow data
"fix" the version 2 workflow data to reflect the real version 2 that was already created in 2023
When adding version 3 workflow data:
Create a version 3 of the versioningWF
Set the start-version step to completed and give it a timestamp that matches the Submitted lifecycle timestamp from the current version 2 - this is as close as we can get to the "real" Opened date for version 3
Set the lifecycle associated with start-version to opened
Then:
Create a version 3 of the accessionWF
Copy over all the data that's currently associated with version 2 of accessionWF, making sure to include the steps that are in "error" or "waiting"
After version 3 workflows have been created, then "fix" version 2 so that it reflects the real version 2 created in 2023:
set all version 2 accessionWF steps that are "waiting" to "completed"
give all version 2 accessionWF step timestamps that match the "Opened" timestamp for version 2
Once these steps are complete, we won't have precisely restored the previous workflow data for version 2, but we will have:
a completed version 2 that reflects lifecycle dates from 2023 (correct day +/- a few minutes or hours)
an in process version 3 that reflects lifecycle dates from 2024 (i.e. the current version being accessioned)
Once all of that is in place, I believe that retrying the sdr-ingest-transfer step will result in the item finishing accessioning with a new version 3 in preservation.
How did these items get into a problem state?
I think the problem was likely created by these objects not being properly "Closed" when they were last accessioned (the original version 2). From what I see in the workflow data, the last steps in the versioningWF were skipped rather than completed back in 2023. That may have meant the version 2 was never "finished" from DSA's perspective. That could be why the latest reaccessioning didn't get applied to a new version 3 and instead started to overwrite the existing version 2.
Additionally
There are 200+ items that have not yet generated version mismatches that are vulnerable to this error. I'm filing a separate ticket to remediate them in the hopes of preventing more version mismatches. If we can get to them before someone tries to accession them, we should be able to prevent this error from recurring.
aaron-collier
commented
1 month ago
The following druids have version mismatch errors in the
sdr-ingest-transferstep in accessionWF:In DSA, these items are at version 2, but preservation already has a version 2. In reality, these druids should be at version 3. This is why the error reads:
I think we can fix the error by doing the following:
When updating the druids, use "reaccession" as the version description. That means both versions 2 and 3 will have the description "reaccession".
Updating the workflow data might not be straightforward. The problem is that the previously existing workflow data from the original version 2 has mostly been overwritten by the current attempt to accession the item. You can see this in the current lifecycles for these objects:
The "Opened" date is the original date that version 2 was created: 2023-08-09. The remaining dates are from the current attempt at accessioning. That means we need to:
When adding version 3 workflow data:
start-versionstep tocompletedand give it a timestamp that matches theSubmittedlifecycle timestamp from the current version 2 - this is as close as we can get to the "real" Opened date for version 3lifecycleassociated withstart-versiontoopenedThen:
After version 3 workflows have been created, then "fix" version 2 so that it reflects the real version 2 created in 2023:
Once these steps are complete, we won't have precisely restored the previous workflow data for version 2, but we will have:
Once all of that is in place, I believe that retrying the
sdr-ingest-transferstep will result in the item finishing accessioning with a new version 3 in preservation.How did these items get into a problem state?
I think the problem was likely created by these objects not being properly "Closed" when they were last accessioned (the original version 2). From what I see in the workflow data, the last steps in the versioningWF were
skippedrather than completed back in 2023. That may have meant the version 2 was never "finished" from DSA's perspective. That could be why the latest reaccessioning didn't get applied to a new version 3 and instead started to overwrite the existing version 2.Additionally
There are 200+ items that have not yet generated version mismatches that are vulnerable to this error. I'm filing a separate ticket to remediate them in the hopes of preventing more version mismatches. If we can get to them before someone tries to accession them, we should be able to prevent this error from recurring.