Ticket #550 (closed defect: wontfix)

Opened 1 year ago

Last modified 6 months ago

articles left in inconsistent state on some ingest errors

Reported by: russ Assigned to: jsuttor
Priority: low Milestone:
Component: ambra Version: 0.8
Keywords: ingest Cc:
Blocking: Blocked By:

Description

some ingest errors result in an inconsistent state - the article is on the 'publishable' list on the admin page, but the zip package has not been moved to the ingested spool.

  • failure to resolve dtd
  • permissions problems on spools
  • probably some other states

we should rollback the ingest in these cases.

Dependency Graph

Change History

08/15/07 10:30:20 changed by amit

  • owner deleted.
  • version changed from 0.7 to 0.8.

I talked with Steve about this and he has an interesting point. We all seem to have a different view of 'published' means. I think we will stick to the idea that once the article has been ingested succesfully in Mulgara/Fedora it is ready to be published. CrossRef? errors can be managed and solved manually as they do not occur that often. However, I do understand that it is confusing for the end-user. Maybe we create and move the file to another 'queue' (say cross-ref) and the file remains there till succesful and only then moved to the ingested queue (or maybe even use the ingested queue as the 'crossref' queue and then move it to a 'backup' queue or something). There might be other better ideas and we will look at this later.

(follow-ups: ↓ 3 ↓ 4 ) 08/15/07 15:20:03 changed by russ

sure, that idea works - anything that doesn't leave things in an inconsistent state, requiring intervention by the administrator, is good.

note that the crossref failure is a block to publication - my understanding is that if you try to publish an article that doesn't have crossref xml when crossref deposits are active, you get an error.

so despite your insistence that we define as "publishable" an article that ingested successfully in mulgara and fedora, it's not actually publishable on the system we've built.

but the semantic point is irrelevant: we can't leave things in a strange in-between state in the ingest app. this becomes drastically more important when we move to command line ingest and there isn't visual feedback telling the operator that things are messed up.

finally, i have no idea how to manually make a crossref deposit and neither does susanne - any hints?

(in reply to: ↑ 2 ) 08/15/07 15:49:43 changed by stevec

Replying to russ:

finally, i have no idea how to manually make a crossref deposit and neither does susanne - any hints?

  • Logon to the system at http://doi.crossref.org
  • Follow the "Upload Submissions" link
  • Choose live or test depending on what you want to do. You can also monitor status of submissions

(in reply to: ↑ 2 ) 08/15/07 15:54:30 changed by amit

Replying to russ:

sure, that idea works - anything that doesn't leave things in an inconsistent state, requiring intervention by the administrator, is good.

Cannot guarantee that in all cases, but in general the above is a good premise for design.

note that the crossref failure is a block to publication - my understanding is that if you try to publish an article that doesn't have crossref xml when crossref deposits are active, you get an error.

Did not know this. Steve will be able to answer this better.

so despite your insistence that we define as "publishable" an article that ingested successfully in mulgara and fedora, it's not actually publishable on the system we've built.

Yes. We would have to change one or the other.

but the semantic point is irrelevant: we can't leave things in a strange in-between state in the ingest app. this becomes drastically more important when we move to command line ingest and there isn't visual feedback telling the operator that things are messed up.

Agreed.

finally, i have no idea how to manually make a crossref deposit and neither does susanne - any hints?

10/29/07 20:48:32 changed by amit

  • owner set to russ.

11/08/07 17:45:11 changed by rich

  • priority changed from medium to low.

12/27/07 17:02:05 changed by russ

  • owner changed from russ to jsuttor.

we've since learned how to make a manual crossref deposit.

this ticket is probably dupe with the #528, but i'll let jeff decide...

12/27/07 18:21:31 changed by jsuttor

  • status changed from new to assigned.
  • milestone set to pubApp_0.8.3.

01/21/08 09:49:46 changed by rich

  • milestone deleted.

06/12/08 20:26:40 changed by amit

  • status changed from assigned to closed.
  • resolution set to wontfix.
  • blocking changed.
  • blockedby changed.

Closing this as this is exactly the opposite of what Rich wanted and we modified. Moving to ingested queue is a courtesy and not a guarantee. Keep copies of the archive around if you want that...:)