Batch Importer (Bib/Acq) (UXPROD-47)

[UXPROD-2615] Ability to kill a long-running or errored data import Created: 11/Aug/20  Updated: 03/Jan/24  Resolved: 21/Oct/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: Q3 2020
Parent: Batch Importer (Bib/Acq)

Type: New Feature Priority: P2
Reporter: Ann-Marie Breaux (Inactive) Assignee: Ann-Marie Breaux (Inactive)
Resolution: Done Votes: 0
Labels: Showstopper-Cornell, data-import, q3-2020-stretch, support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-47 Batch Importer (Bib/Acq) Analysis Complete
is defined by MODSOURMAN-361 Add capability to remove jobs that ar... Closed
is defined by UIDATIMP-655 Data imports can get stuck at "Runnin... Closed
is defined by UIDATIMP-651 Add capability to remove jobs that ar... Closed
Epic Link: Batch Importer (Bib/Acq)
Development Team: Folijet
PO Rank: 101
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R3
Rank: Grand Valley (Full Sum 2021): R2
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

When a data import is taking too long (and may have died without an indication), user should have the ability to manually stop that data import job.

TBD: when a job is stopped, what should happen?

  • Retain as much as had created/updated properly, and add to log as Completed with errors?
  • Roll back everything that may have created/updated, and add to log as Failed?
  • Any indication needed that a user stopped the job (and if so, who)?
  • What else?

Question - what about existing jobs that are stuck (see EBSCO demo account for examples). Can they be retroactively updated so that they can be stopped?



 Comments   
Comment by Kelly Drake [ 31/Aug/20 ]

Ann-Marie Breaux, both MSU and Leigh are now running into this issue in their production environments. Would it be possible to upgrade this to a bug - and a P2 at that, since the only workaround is that they have to run their updates in their Test environments and if they fail, then not run them in production at all.

Comment by Kelly Drake [ 15/Sep/20 ]
  • the backend should be responsible for logging that a process ended unsuccessfully (maybe the process died unexpectedly, maybe there was a data processing error; either way, “ended without success” should be reported in a predictable, consistent manner)
  • when a backend process ends without success, the UI should be able to report this.
Comment by Ann-Marie Breaux (Inactive) [ 15/Sep/20 ]

Hi Kelly Drake Yes, that's the intention. We just haven't written the actual front-end and back-end stories to deal with this feature yet.

Comment by Anya [ 15/Sep/20 ]

would second the bug ...

Comment by Ann-Marie Breaux (Inactive) [ 15/Sep/20 ]

Hi Anya and Kelly Drake I got with Kimie today and figured out a UI model that we can copy to handle this. Clean UI and MOD stories have been created. If you would like to create a bug, please link to the above UI and MOD issues. Thank you!

Comment by Lisa McColl [ 16/Sep/20 ]

Bug created: https://folio-org.atlassian.net/browse/UIDATIMP-655

Comment by Karen Newbery [ 22/Sep/20 ]

It is very important that we have a way to kill jobs that have stopped from errors. Based on feedback from other implementers in production, they frequently run into an issue where a job has errored out. We would need to be able to kill jobs that act that way.

Comment by Ann-Marie Breaux (Inactive) [ 28/Sep/20 ]

Hi Karen Newbery Yes, we're going to try to squeeze this into the Honeysuckle release. Stay tuned!

Generated at Fri Feb 09 00:25:26 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.