search

sul-dlss-deprecated / sdr-preservation-core

Robots for ingesting objects into SDR Preservation Core -- replaced by preservation_robots
Other
1 stars 0 forks source link

Review complete deposit crash recovery #5

Open dazza-codes opened 10 years ago

dazza-codes commented 10 years ago

See JIRA issue LEGACY-978.

A new verision bag was ingested, then a segfault occurred during the new version validation, at https://github.com/sul-dlss/sdr-preservation-core/blob/master/lib/sdr_ingest/complete_deposit.rb#L35

So, a new deposit was ingested into storage, but not verified (complete deposit didn't finish and ingest cleanup didn't run to remove the deposit etc.). We should consider whether this section of code should handle exceptions and remove the storage data if it fails verification. Part of this scenario is that sdr-services-app can find the storage data (which has not been validated) and therefore it reports that version X exists already. Maybe the complete deposit process should record some kind of file system status (ingesting - ingested - validating - validated - completed); so that sdr-services-app (or anything inspecting the storage data) can check this status info in a file within the druid path (or elsewhere)? This is a complicated issue that spans sdr-preservation-core, sdr-services-app, workflow-service, and moab-versioning (among other systems?).

dazza-codes commented 10 years ago

We discussed this and it was proposed that the complete-deposit step could be split up. The split is likely something like 'moab-ingest' and 'moab-validate' steps.

dazza-codes commented 10 years ago

We discussed an automated solution for crash recovery. It was decided that automated recovery is not required, because we want human intervention. (Details on resolving this will be handled in JIRA:LEGACY-978.)

dazza-codes commented 10 years ago

Review of spec test coverage indicates that only about 60% of the code in complete_deposit is tested. While working on this issue, test coverage should be improved.