Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manifest regeneration enhancements [placeholder] #2208

Open
6 tasks
eporter23 opened this issue Sep 27, 2023 · 0 comments
Open
6 tasks

Manifest regeneration enhancements [placeholder] #2208

eporter23 opened this issue Sep 27, 2023 · 0 comments
Labels

Comments

@eporter23
Copy link
Contributor

eporter23 commented Sep 27, 2023

Story

As a Library Staff Depositor, I want to reduce the frequency of automatic manifest regenerations that may occur, so that this resource-intensive process is not triggered unless explicitly called

Acceptance Criteria

Use one or more of the following options to provide acceptance criteria.

Notes

The original manifest generation process was built several years ago, and includes a behavior that will automatically generate or re-generate a manifest if 1) a cached manifest does not exist or 2) if certain changes are made to a work's metadata, visibility, or FileSets. In production, we anticipate that not all works will have a cached manifest, because we had been ingesting material prior to developing our most recent caching strategy.

We later did work to try to optimize this behavior and resolve a bug where the manifest generation job would execute multiple times for the same work as a result of viewing a work before its completed manifest was cached. This bug still occasionally recurs, however, and is particularly problematic for large book objects, where the manifest generation can take anywhere from 20 minutes or longer to complete. This behavior is also problematic when we are attempting to re-index works for full text searching, because the addition of a new fileset will result in a manifest being generated, even though the Fulltext file being attached is not immediately utilized in the manifest. Additionally, we may want to add the Fulltext Data file as a download option in the UV, and editing the work to make that change will result in a second manifest regeneration process.

Links to Additional Information

Add links here

Possible Tasks

  • Identify works that do yet not have a cached manifest in production
  • Manually generate manifests for the above works
  • Disable automatic generation and re-generation of manifests in Curate and Lux for specific conditions (TBD)
  • Determine what a user should see if they happen to encounter a work without a manifest
  • Implement any needed changes related to the above
  • Update training and support documentation to assist Curate users related to any changes

Given/When/Then

  • Given (some context) and (some other optional context)
  • When (some action is carried out)
  • Then (a set of observable consequences should occur)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant