Version loss after closing new version.

[jcoyne]

Given: An existing Hydrus object with multiple versions
When: I open a new version on the object in Hydrus, and make no changes, then close the version
Then: all the version entries in versionMetadata are erased

What should happen: ???

It this is believed to be a regression, when was the last time it worked correctly?

[blalbrit]

In this particular instance, there was an object (zn881hy2689) that had failed to complete processing due to an "unknown status" error that was a direct result of broken versionMetadata:

To correct the error, I fixed the broken version 2 stanza and closed the version of the object, which then erased the version 2 stanza altogether and began processing the object as if it were version 1 again. This appears to be due to the fact that the versionMetadata.xml file in the Hydrus copy of the file (/data/hydrus-files/zn/881/hy/2689/zn881hy2689/metadata) was used to overwrite the datastream in DOR.

The expectation would be that new versions created in Hydrus, or versions of the object handled through Argo, would start from the latest version of versionMetadata in DOR.

Of course, it's unclear what happens when that versionMetadata is broken as in the case of this object.

[blalbrit]

Verified that the broken versionMD was at the root of this particular object problem. I have found no other Hydrus objects in a similar state and assume that this was an ephemeral problem. We'll track versioning in Hydrus for a bit, but have seen no other errors in the last few days.

[blalbrit]

Actually - this looks like an ongoing problem now. See https://argo.stanford.edu/view/druid:vq436sq9834 and https://argo.stanford.edu/view/druid:hm222bn8688 for instance. Both done today, between 12 and 1.

To characterize the problem, when a new version gets opened in Hydrus, it is getting an incomplete versionMetadata stanza which puts it into an "unknown status". The user in the Hydrus app gets a HTTP ERROR 500.

When we try to repair the object on the Argo side, we then see the behavior noted above. @cbeer and @jcoyne - I would imagine that 500 is being logged somewhere.

[blalbrit]

See also https://app.honeybadger.io/projects/49897/faults/34310019