Why does the transfer-object robot verify that versionMetadata exists?

[jcoyne]

https://github.com/sul-dlss/preservation_robots/blob/main/lib/robots/sdr_repo/preservation_ingest/transfer_object.rb#L33

I don't think this is necessary. We already verify the bag in dor-services-app before kicking off the workflow:
https://github.com/sul-dlss/dor-services-app/blob/2ac9d78e999eb9a738a8c887d0b6e2f0ce726730/app/jobs/preserve_job.rb#L23-L27
https://github.com/sul-dlss/dor-services-app/blob/2ac9d78e999eb9a738a8c887d0b6e2f0ce726730/app/services/sdr_ingest_service.rb#L39

Let's try switching to use contentMetadata.xml instead.

[andrewjbtw]

A bag can be valid without a versionMetadata.xml so if you have to have a versionMetadata.xml then you have to check for that file specifically. If you don't have to have a versionMetadata.xml (or any other specific file within the /data directory bag), you don't need to check for it. I would guess that there was or maybe still is a dependency on having versionMetadata.xml in the bag so they put in a check for that specific file.

[jcoyne]

@andrewjbtw I agree, but we already check for it here: https://github.com/sul-dlss/dor-services-app/blob/2ac9d78e999eb9a738a8c887d0b6e2f0ce726730/app/services/sdr_ingest_service.rb#L129

[justinlittman]

Is there an action on this ticket?

[jcoyne]

I think we want to figure out why versionMetadata.xml is the target and if we can switch it to be something else, because we are probably not going to generate versionMetadata.xml in the future.

[jmartin-sul]

here's what i found when looking into this yesterday:

• i don't know that i can see why it's needed. the only references to it in pres robots are in lib/deposit_bag_validator.rb and lib/robots/sdr_repo/preservation_ingest/transfer_object.rb
  • seems like we just really want to be sure we have it? it's the only fedora datastream among the REQUIRED_BAG_FILES :

    preservation_robots/lib/deposit_bag_validator.rb

    Lines 45 to 54 in b157134

    	REQUIRED_BAG_FILES = [
    	DATA_DIR_BASENAME,
    	'bagit.txt',
    	BAG_INFO_TXT_BASENAME,
    	"#{MANIFEST}-#{REQUIRED_MANIFEST_CHECKSUM_TYPE}.txt",
    	"#{TAGMANIFEST}-#{REQUIRED_MANIFEST_CHECKSUM_TYPE}.txt",
    	VERSION_ADDITIONS_BASENAME,
    	VERSION_INVENTORY_BASENAME,
    	VERSION_METADATA_PATH
    	].freeze

• i don't see any reference to it in the moab-versioning gem either. seems like moab-versioning doesn't care, as long as there's a valid bag to work with.
• hard to say what the intent was, whether it was just a proxy for "did the datastreams get exported?" (under the assumption that one's always there? sometimes seen missing? 🤷) or something else entirely
• maybe we should test accessioning and versioning an object without versionMetadata.xml, on a branch w/ the check disabled, to see if it works
• as @jcoyne points out, there's a check done on DSA side already, and the check from pres robots is before the tarpipe to the deposit dir, it just sshes to dor-services to do the check that DSA already just did (so this is not analogous to pres cat verifying a new moab version after it's been created by copying files from the deposit bag to the new moab version, which involves bits being written anew from the deposit dir to the storage root)
• people to ask if we really wanted to understand the intent: ben, lynn, richard anderson

[ndushay]

@jcoyne - are we still generating versionMetadata.xml?

What should we use instead? can we use the cocina json file? Or ???

[jcoyne]

Yes, we are still generating versionMetadata.xml, but mostly because we have this check. I think switching the check to look for bagit.txt would be better (cocina.json would also work). But I'm not sure we really need this check at all because we already have a validator that ensures the bag has all the required files.