Re-validate version metadata during unembargo #1989
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you, Jake. |
Also add test to check that versions validated with a status besides `PENDING` are skipped
jjnesbitt
force-pushed
the
unembargo-version-metadata
branch
from
b47a06c
to
c9ffca1
Compare
mvandenburgh
approved these changes
Aug 14, 2024
|
🚀 PR was released in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses what I believe to be the cause of dandi/helpdesk#158. Previously, when a dandiset was unembargo, we re-populated the version metadata but never validated it. This is in contrast to the normal flow of updating a version, which sets its status to
PENDINGand is eventually validated.Now, this is performed inline as a part of unembargo.
@danlamanna Curious about your thoughts on my changes and additional test for
validate_version_metadata. Previously, we assumed that versions with a status besidesPENDINGwere passed into the function correctly, and were concurrently modified, changing the status. However, the function could easily be called mistakenly with a different version status, and so I think the log message should be updated to reflect that.