-
Notifications
You must be signed in to change notification settings - Fork 178
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
fix(api): fix run cancellation freezing on legacy core #14312
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## edge #14312 +/- ##
==========================================
+ Coverage 68.06% 68.09% +0.03%
==========================================
Files 1621 2503 +882
Lines 54710 71589 +16879
Branches 4087 9113 +5026
==========================================
+ Hits 37238 48750 +11512
- Misses 16817 20711 +3894
- Partials 655 2128 +1473
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
Looks great but we might have to dig deep and make sure we're not causing reentrancy issues.
ca0f462
to
ba2f1ff
Compare
Tested the above protocol with API versions 2.11 & 2.15 and verified that the protocol cancels cleanly when:
|
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.
This looks good to me!
@@ -906,21 +907,21 @@ def engaged_axes(self) -> Dict[Axis, bool]: | |||
return self.get_engaged_axes() | |||
|
|||
async def disengage_axes(self, which: List[Axis]) -> None: | |||
# Should this have wait_for_running decorator too? |
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.
Talked with Seth about this and the conclusion is that we should not because disengaging is a quick and harmless action and we shouldn't wait for running for everything without a good reason.
* communicate with smoothie via cancellable tasks during drop_tip movement and home_plunger
Import ParamSpec from typing breaks compatibility with Python 3.8 and 3.9: https://docs.python.org/3/library/typing.html#typing.ParamSpec. This means OT is now only compatible with Python 3.10. Can you import it from typing_extensions on 3.8/9 to restore compatibility? I can make a PR if you want. |
Closes RESC-184, RQA-2273
Overview
Successful cancellation of a protocol run using the legacy core relies on making sure that all OT2 robot movements (and delays) happen inside tasks that can be cancelled when a protocol cancel request comes in. But we seem to have missed a few robot movements which were neither wrapped inside cancellable tasks, nor were checking the execution manager status to make sure the robot is okay to be moved.
This PR aims to fix that by putting all such stray direct calls to smoothie inside cancellable tasks.
Right now I've only fixed the direct calls in
ot2api.drop_tip()
and tested to confirm it fixes the freezing problem. I will be going through rest of the ot2 api to fix any other calls if they exist.Update:
home_plunger
also was not being taskified so fixed that as well.Test Plan
Changelog
drop_tip
home_plunger
methodwait_for_running
decorator implementation!Review requests
_move()
is called inside taskifiedhome()
)Risk assessment
Medium. Fixes a bug but also re-arranges a few methods decorated behind
wait_for_running
. For this reason, we should review and QA this thoroughly