search

sul-dlss-deprecated / hydrus

[DEPRECATED] Superseded by https://github.com/sul-dlss/happy-heron/ An application for self-deposit of digital objects into the Stanford Digital Repository for preservation and access.
Other
12 stars 4 forks source link

Version loss after closing new version. #148

Open jcoyne opened 7 years ago

jcoyne commented 7 years ago

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 commented 7 years ago

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: screenshot 2017-08-04 09 28 10

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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