🦄 Bulkrax imports always succeeds when it shouldn't

[ShanaLMoore]

We think this behavior broke sometime before version 5.2.1 (per Jeremy).

It seems like bulkrax got updated. Clients are complaining that failed job are still being reported as completed.

[jeremyf]

I suspect the reason we are not seeing errors in Bulkrax is because the ImportWorkJob is succeeding; which governs the Completed status of jobs.

The ImportWorkJob then submits other jobs (in particular SplitPDF Job) then reports it's status. The newly submitted jobs are not part of the reporting process for import entry status.

Fundamentally, the status is not reflective of the true state of the various jobs that are in play. This is confounded by the fact that Bulkrax does not know about IiifPrint.

[jeremyf]

Course of Action:

Consider that the singular ImportWorkJob is not the authority on the success/failure of the import entry run. Instead, it relates to a series of subsequent jobs. And some of those jobs are optional (e.g. we don't split non-PDFs meaning that the PDF splitting is not always the terminal). Also there is the relationship job that's also in play.

Some options to consider:

• Add the current run and entry id to the job's signature (this would be a breaking change and necessitate upgrading to Bulkrax v6.0.0)
• During each method's perform, if it submits a job, it's not responsible for reporting activity.
• Refactor towards this structure
  • This will involve assessing what all jobs are in play.
  • Jeremy wrote https://github.com/jeremyf/job_grapher/ which might help finding all of these in a project
• Document the pattern as we'd need this to be by convention.