-
Notifications
You must be signed in to change notification settings - Fork 179
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
refactor(api): Port touchTip
, liquidProbe
, and tryLiquidProbe
location updates to StateUpdate
#16261
refactor(api): Port touchTip
, liquidProbe
, and tryLiquidProbe
location updates to StateUpdate
#16261
Conversation
* No need for two whole separate functions that only differ in the get_is_ready_to_aspirate() mock's return value, especially when the subject ignores that return value. * Remove a redundant verify().
well_location=params.wellLocation, | ||
) | ||
except PipetteLiquidNotFoundError as e: | ||
return e, state_update, deck_point |
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.
if its ok can we return a data model instead of a tuple? I find it confusing that the first arg can be an error/z pos
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.
I'm using a NamedTuple
now, which is a little better, but I'm still cramming a float
and Exception
into a single attribute, which sounds like the real point of confusion.
I think I'd like to keep that as-is for type safety reasons. There will always either be a "no liquid found" condition with exception details, or there will be a z_pos
, so I'd rather represent that in the type system than use assert
s or whatever. I do see your point about it being confusing when two totally different things are in a single attribute.
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! a small nip we spoke about in person :-)
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.
Thank you for taking the time to try and fix my nip! Lgtm!
## Overview A trivial refactor as part of EXEC-652. ## Changelog The `DefinedErrorData.private` attribute was obsoleted by PR #16160's `StateUpdate` mechanism. PR #16261 deleted the last use of it, so we can delete the attribute now. `DefinedErrorData`'s sibling class, `SuccessData`, also has an identical `private` attribute. We're not quite ready to delete that one, though.
Overview
More incremental work towards EXEC-652.
Test Plan and Hands on Testing
Changelog
This continues the pattern started in #16160. The following commands now use the new
StateUpdate
mechanism to update the pipette's logical state for the purposes of path planning:touchTip
liquidProbe
tryLiquidProbe
Review requests
Double-check that the behavior of the code that I'm removing from
PipetteStore
is exactly preserved by the code I'm adding toTouchTipImplementation
,LiquidProbeImplementation
, andTryLiquidProbeImplementation
.Risk assessment
Medium.