-
Notifications
You must be signed in to change notification settings - Fork 232
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
Minor Work Items fixes #1116
Minor Work Items fixes #1116
Conversation
@@ -1109,17 +1117,15 @@ def _release_on_failure(self, attributes): | |||
state=State.FAILED, | |||
exception_type=Error.APPLICATION, | |||
message=message, | |||
_auto_release=True, | |||
_internal_release=True, |
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.
@osrjv Like you thought, wondering if now it makes sense to just release all the non-released items as FAIL
during the failed Step Run. (iterating through all the inputs and checking if there's one that wasn't released and for each applying this kind of release)
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.
Never mind, we decided to pull back the auto_release
switch.
Tested locally and in Control Room with the following processes: |
This change will allow users to be able to reserve new inputs without being obliged to release the lastly retrieved item. This can be achieved explicitly by settingauto_release=False
when calling keywords likeGet Input Work Item
andFor Each Input Work Item
.A couple of other bugfixes along the way:
Slack thread
Test Task package
CR Process