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

[DAR-5014][External] Better error messaging when importing to items not ready to receive annotations #978

Merged
merged 1 commit into from
Dec 3, 2024

Conversation

JBWilkie
Copy link
Collaborator

@JBWilkie JBWilkie commented Dec 2, 2024

Problem

This ticket tackles 2 problems:

  • 1: When importing annotations to items not ready to receive them, imports would fail without any error handling. These are items in the uploading, processing, error, and archived statuses
  • 2: When importing NifTI annotations, if any item in the dataset was not in a state to receive annotations (even an item not targeted by the import), the import would fail without any error handling. This is happening due to the fetch_remote_files() call in _get_remote_files_that_require_legacy_scaling() not filtering for item status, then trying to retrieve slot information

Solution

  • 1: If an import job is trying to import annotations to item(s) not ready to receive them, we raise an error and display which items are affected and what statuses they are in
  • 2: When importing NifTI annotations, we only retrieve items in valid import statuses in the _get_remote_files_that_require_legacy_scaling() function. If there are items not ready to receive annotations, they will be found later in the import flow by _get_remote_files_ready_for_import()

Changelog

Better error handling and messaging when importing annotations to items not ready to receive them

remote_files = self.fetch_remote_files()
remote_files = self.fetch_remote_files(
filters={"statuses": ["new", "annotate", "review", "complete"]}
)
Copy link
Contributor

@dorfmanrobert dorfmanrobert Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are workflow statuses not processing statuses right? PR description mentions uploading, processing, error, and archived; is that what should be used here?

Copy link
Collaborator Author

@JBWilkie JBWilkie Dec 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the status that list_items returns. In the backend, this is GeneralStatus, so it accounts for processing status

We need to use this status type, because list_items doesn't allow filtering based on processing status

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha thanks, I guess it would be nice to have types/objects that can be used for these but maybe a separate piece of work

@JBWilkie JBWilkie force-pushed the DAR-5014 branch 2 times, most recently from 0c93e7b to 3b73f73 Compare December 2, 2024 16:12
@JBWilkie JBWilkie merged commit 5b84d91 into master Dec 3, 2024
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants