Segment large batch processes

[K8Sewell]

Story
As described in a comment in #2859, sometimes a job may time out and fail before all records in a CSV are processed. This causes some jobs to run multiple times. We would like to change the batch process behavior to process CSVs in segments of 50 rows at a time, to prevent process from timing out and re-running.

This behavior should be applied to the following batch processes:

• DeleteParentObjects
• ReassociateChildOids
• RecreateChildOidPtiffs
• UpdateParentObjects
• CreateParentObjects

Acceptance
The following jobs run in segments of 50 rows until completion:

• DeleteParentObjects
• ReassociateChildOids
• RecreateChildOidPtiffs
• UpdateParentObjects
• CreateParentObjects

Engineering Notes
Jobs that have batching patterns to pull from:

• SolrReindexAll
• UpdateAllMetadata
• UpdateDigitalObjects
• UpdateManifests

[jpengst]

I know it's a long shot since it was back in June; but does anyone remember which GoodJob error this delete parent objects job was receiving? (https://collections-uat.library.yale.edu/management/batch_processes/2039).

It would have only been displayed on the main GoodJob Dashboard under the jobs name. Ex:

[K8Sewell]

PR ready for review - yalelibrary/yul-dc-management#1475

[jpengst]

Deployed to Test v2.74.2

[jpengst]

Confirmed that this is working on demo.
On Test, solr falls over with this error:

[sshetenhelm]

I feel like something strange is going on with the 'UpdateParentObjects' batch process. It's taking waaaay longer than I would expect to just update a single metadata field. The first parent received a 'Complete' but the rest have 0 status information.
Batch process -- https://collections-uat.library.yale.edu/management/batch_processes/2560

[sshetenhelm]

Two objects had "Digital Object Source = None" but got dinged for not having a Preservica UUID. Also, Management tried to run them both like 15 times, and each time wrote an error in the batch process message:

Management also reported not being able to log into to Preservica for a number of objects that have already been uploaded via Preservica. Also, why would it check Preservica if the object is just updating the 'Extent of Digitization' field?

[jpengst]

Looking into why those "Digital Object Source = None" objects are being treated like Preservica objects. Thats weird.

For the second issue, we always sync from preservica when we update preservica objects. I just tried updating one of the "Unable to login" objects with a single line CSV upload and it updated the extent_of_digitization successfully with no errors. Im looking into this. Putting back in progress.

[jpengst]

This ticket was spawned from this job (https://collections-uat.library.yale.edu/management/batch_processes/2039) that failed and reran multiple times because GoodJob lost connection and timed out. Instead of segmenting the jobs, it would be cleaner to have more robust error handling by rescuing and returning the specific GoodJob error. The main issue with this is that we no longer have the original GoodJob error to reference.

Putting this in Backlog. If a future job fails for a lost GoodJob connection, we will have the error to reference and can implement better error handling.