-
Notifications
You must be signed in to change notification settings - Fork 73
[SYNPY-1590] Implement core functionality of Submission(+Status, +Bundle) OOP model #1251
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
base: synpy-1590-submission-model-main
Are you sure you want to change the base?
[SYNPY-1590] Implement core functionality of Submission(+Status, +Bundle) OOP model #1251
Conversation
8b50d06 to
a061fb4
Compare
62ce5fb to
f0d7ecc
Compare
a061fb4 to
c748132
Compare
…issionstatus file
…rn as evaluations design
…OR submission annotations
| return entity_info | ||
| except Exception as e: | ||
| raise ValueError( | ||
| f"Unable to fetch entity information for {self.entity_id}: {e}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason not to do
raise ValueError(msg) from e ?
| docker_tag_response = await client.rest_get_async( | ||
| f"/entity/{self.entity_id}/dockerTag" | ||
| ) | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be an api function?
| request_body["dockerRepositoryName"] = self.docker_repository_name | ||
| if self.docker_digest is not None: | ||
| request_body["dockerDigest"] = self.docker_digest | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a list of optional fields and then use a for loop to iterate over them, and them to the request body if they are not none?
| Raises: | ||
| ValueError: If any required attributes are missing. | ||
| """ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be an example for this method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I don't think so, as this method won't be surfaced in the documentation. I could turn it into a hidden function instead?
| Returns: | ||
| A dictionary containing the request body for updating a submission status. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #1251 (comment)
| request_body["canCancel"] = self.can_cancel | ||
| if self.cancel_requested is not None: | ||
| request_body["cancelRequested"] = self.cancel_requested | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same suggestion as Submission about turning this into a for loop.
| except Exception as e: | ||
| raise ValueError( | ||
| f"Unable to fetch entity information for {self.entity_id}: {e}" | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be catching every possible exception here and assuming they're all the same cause, or would it be useful to break the catching up into synapse errors and other possible kinds? Also would a LookupError make more sense here than a ValueError?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, we could do raise ValueError(msg) from e here. Then the user would still get a ValueError but would also see the exception that was caught as well.
tests/integration/synapseclient/models/async/test_submission_async.py
Outdated
Show resolved
Hide resolved
tests/integration/synapseclient/models/async/test_submission_status_async.py
Show resolved
Hide resolved
|
|
||
| # THEN the batch update should succeed | ||
| assert response is not None | ||
| assert "batchToken" in response or response == {} # Response format may vary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what causes the response formats to vary? should those be different parametrizations for this test?
tests/integration/synapseclient/models/synchronous/test_submission.py
Outdated
Show resolved
Hide resolved
| assert ( | ||
| submission_status.status is not None | ||
| ) # Should have some status (e.g., "RECEIVED") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment as similar one above
|
Looking good so far! I didn't see any deprecations, will you be doing that as part of this PR? |
c748132 to
31d9583
Compare
* always log warning * check assert called with * patch object on class instance * Revert "always log warning" This reverts commit ae63c81. * update patch target * re-add erroneously removed line
@andrewelamb that's been done in PR #1252 which I'll address after addressing all the threads here. |
See #1250
All tests passing: