Complete deposit for work 5264

[amyehodge]

Work 5259 shows in the UI (https://sdr.stanford.edu/works/5259) with the "Deposit in progress" text and the spinning icon.

@andrewjbtw has set the state back to draft but we need the UI to be updated so the spinning icon is not displayed.

The depositor tried to upload about 60GB of files and I will be contacting him to send the content to us via Globus.

[andrewjbtw]

To add more detail, I stopped the deposit from running in sidekiq because it's going to keep timing out because the total volume of files is so large. It's currently the one "killed" job listed here: https://sdr.stanford.edu/queues

It doesn't look like the spinning icon is changed automatically except for when a deposit is successful.

[peetucket]

There is currently a single version of this work and it is indeed in the state "depositing" in the database:

Work.find(5259).work_versions
 =>
[#<WorkVersion:0x00000000070c7860
  id: 5681,
  version: 1,
  title: "Minke whale data",
  work_type: "mixed material",
  created_edtf: "2022-03-22",
  abstract:
   "IMU, video and UAV data from Antarctic minke whales collected in 2018 & 2019. Submitted with \"Minimum body size constraints on engulfment filtration feeding \"",
  citation:
   "Cade, D., Kahane-Rapport, S., Gough, W., Bierlich, K., Linsky, J., Calambokidis, J., Johnston, D., Goldbogen, J., and Friedlaender, A. (2022). Minke whale data. Stanford Digital Repository. Available at :link will be inserted here automatically when available:",
  access: "world",
  embargo_date: nil,
  license: "CC-BY-NC-SA-4.0",
  created_at: Wed, 23 Mar 2022 00:55:58.331993000 UTC +00:00,
  updated_at: Wed, 23 Mar 2022 20:58:10.932433000 UTC +00:00,
  state: "depositing",
  published_edtf: nil,
  subtype: ["Data", "Image", "Video"],
  work_id: 5259,
  description: nil>]

This code suggests the state before "depositing" is "begin_deposit": https://github.com/sul-dlss/happy-heron/blob/main/app/models/work_version.rb#L67-L69

So in theory we can update the database to set the state back to "begin_deposit" like this:

Work.find(5259).work_versions.first.update_column('state','begin_deposit')

But it's not clear to me right now if that has any unintended side effects.

[ndushay]

the last time we had an endlessly spinning wheel, I solved it by opening and closing a new version (I think) via argo. Does this work have a druid yet?

[jmartin-sul]

@peetucket i think begin_deposit is the name of the transition event, and the states that it can happen on are first_draft, version_draft, and pending_approval. so i think we'd want to put it back into one of those states, but it also seems like the only valid state transitions for something that's depositing are pid_assigned (stays in depositing) and deposit_complete (goes to deposited).

i'm not sure if there are possible unintended side effects of going around the state machines hooks and updating states manually. i guess we'd probably want to see what side effects the begin_deposit transition has?

https://github.com/sul-dlss/happy-heron/blob/main/doc/state_machines/WorkVersion_state.svg

i like @ndushay's idea, i also recall us doing that, but am not 100% sure that's the right thing to do.

i think @jcoyne is the person most familiar with the state machines gem and H2's use of it.

[ndushay]

I don't think this has a druid yet. But what do I know?

[peetucket]

Thanks John, was misreading the state definition code.

It does not appear to have a druid yet:

Work.find(5259)
  Work Load (0.6ms)  SELECT "works".* FROM "works" WHERE "works"."id" = $1 LIMIT $2  [["id", 5259], ["LIMIT", 1]]
 =>
#<Work:0x00000000074916f8
 id: 5259,
 druid: nil,
 head_id: 5681,
 collection_id: 137,
 depositor_id: 1032,
 created_at: Wed, 23 Mar 2022 00:55:58.330130000 UTC +00:00,
 updated_at: Wed, 23 Mar 2022 00:55:58.366797000 UTC +00:00,
 assign_doi: true,
 doi: nil>

So perhaps going back to "first_draft" is correct?

[amyehodge]

This work does not yet have a druid, and I think getting one is going to be problematic because the files can't be uploaded -- and a file is required. "first_draft" is the correct state for this. We will attach the files from the back end because they are too big for H2.

[peetucket]

Since the DepositJob was killed cause it was taking too long, I think we can just reset the state to first_draft to get back to the point before the deposit button was pushed. Though I am not 100% confident of "going around" the state machine in this way. If urgent, we can try it - i think the worst that can happen is that it doesn't work, but it may get the object into another peculiar state. If not super urgent, may be nice for Justin to weigh in if he's working tomorrow.

[amyehodge]

@peetucket It can wait for Justin's input. The depositor has actually not contacted us about it yet -- @andrewjbtw noticed this was happening -- and may not be aware yet.

[mjgiarlo]

Sorry for the premature close on this issue. I didn't realize that "may also fix" in https://github.com/sul-dlss/sdr-client/pull/168 would auto-close this issue.

[amyehodge]

Please keep this item: druid pm378wm1385/work 5264 This duplicate item can be deleted: work 5259

[mjgiarlo]

I will work with @lwrubel on this next week.

[peetucket]

work 5259 has been removed

[peetucket]

Leaving this ticket open and renamed to reflect next step which is to complete deposit of 5264

[mjgiarlo]

I'm planning to take a look at this tomorrow after @lwrubel deploys H2 (et al.) to prod.

[mjgiarlo]

@amyehodge This deposit has now gotten into SDR API and is working its way through the accessioning workflow. Watching these steps as the day goes on. Technical metadata is happening now. Between that and preservation, we're not quite out of the woods yet.

[mjgiarlo]

@amyehodge All workflows have completed and this object is now fully deposited. I have a pending sdr-client pull request which will make the changes necessary to accommodate objects of this size going forward. Feel free to close the issue if you think we're good for now.

[amyehodge]

Looks good!