reconcile Cocina object versions with actual preserved object versions

[andrewjbtw]

The SDR has supported versions via Moab versioning for many years, but for many of those years SDR also had problems keeping version information in sync across Fedora, the workflow service (which records version numbers), and preservation. This resulted in numerous errors where version mismatches blocked accessioning: Fedora said object is on version N, but preservation said version N +- 1).

The most common way to handle version mismatch errors was to edit the versionMetadata datastream (see the now-deprecated instructions). These edits were sufficient to allow objects to finish accessioning, but behind the scenes this apparently left behind inconsistent version metadata. This is a class of problem that remains hidden until someone tries to update an affected druid. No repository process monitors for mismatched version metadata across the various systems.

Two examples:

rt675ky1058 dj813zv3194

Both of these items say they are on version 3, according to Cocina/DSA. But the history shows only two versions. But these versions are numbered 1 and 3.

The workflows also suggest only two versions have been updated, 1 and 3: The accesionWF should be recorded in the workflow DB for every accessioned version.

Preservation also has only 2 versions, but these are numbered the expected way, 1 and 2:

./rt675ky1058/v0001
./rt675ky1058/v0002

Impact

It's not possible to open items in this state and create new versions. Attempting to open rt675ky1058 leads to this error:

Dor::Services::Client::UnexpectedResponse: Unable to open version (Version from Preservation is out of sync. Preservation expects 2 but current version is 3)

I think that means preservation expects to be told the current version is 2 and the next version is 3, but it's being told the current version is 3.

Reconciliation options

There are at least two possible ways to handle this:

• Create the "missing" version in preservation to sync with version in DSA
  • in the examples above, we'd deposit version 3 for each of these items
• Change the DSA version numbers to match the numbers in preservation
  • in the examples above, we'd make DSA correspond to the 2 versions in preservation

Next steps

Either way, we'll need to generate a report for this issue. There were many version mismatch problems in the history of SDR. Possibly tens of thousands of version mismatch problems.

[justinlittman]

Here's the report @andrewjbtw

preservation_versions_report.csv

[andrewjbtw]

Only 442 items, which is a relief.